Value types need not be immutable. But they are.
In the previous post I discussed the difference between pointers and references in Java and how the method parameters are passed (passed-by-value or passed-by-reference). These are strongly related to value types that do not exist in Java (yet).
There is a proposal from John Rose, Brian Goetz, and Guy Steele detailing how value types will/may work in Java and also there are some good articles about it. I have read “Value Types: Revamping Java’s Type System” that I liked a lot and I recommend to read. If the proposal is too dense for you to follow the topic you can read that article first. It summarizes very much the background, what value types are, advantages, why it is a problem that Java does not implement value types and why it is not trivial. Even though the terminology “value type” may also be used to denote something different I will use it as it is used in the proposal and in the article.
How do we pass arguments vs. what do we store in variables
As you may recall from the previous article I detailed that Java passes method arguments by reference or by value depending on the type of the argument:
- reference is passed when the argument is an object
- by-value when the argument is primitive.
There are some comments on the original post and also on the JCG republish that complain about my terminology about passing an argument by-reference. The comments state that arguments are always passed by value because the variables already contain reference to the objects. In reality variables, however contain bits. Even though this is important to know how we imagine those bits, and what terminology we use when we communicate. We can either say that
- class variables contain objects and in that case we pass these objects to methods by-reference
- or we can say that the variables contain the reference and in that case we pass the value of the variables.
If we follow the thinking #1 then the argument passing is by-value and/or by-reference based on the actual nature of the argument (object or primitive). If we follow the thinking #2 then the variables store reference and/or values based on the nature of their type. I personally like to think that when I write
Triangle triangle;
then the variable triangle is a triangle and not a reference to a triangle. But it does not really matter what it is in my brain. In either of the cases #1 or #2 there is a different approach for class types and for primitives. If we introduce value types to the language the difference becomes more prevalent and important to understand.
Value types are immutable
I explained that the implicit argument passing based on type does not cause any issue because primitives are immutable and therefore, when passed as method argument, they could not be changed even if they were passed by reference. So we usually do not care. Value types are not different. Value types are also immutable because they are values and values do not change. For example the value of PI is 3.145926… and it never changes.
However, what does this immutability mean in programming? Values be real numbers, integers or compound value types are all represented in memory as bits. Bits in memory (unless memory is ROM) can be changed.
In case of an object immutability is fairly simple. There is an object somewhere in the universe that we can not alter. There can be numerous variables holding the object (having a reference to it) and the code can rely on the fact that the bits at the memory location where the actual value of the object is represented are not changed (more or less).
In case of value types this is a bit different and this difference comes from the different interpretation of the bits that represent a value type from the same bits when they may represent an object.
Value types have no identity
Value types do not have identity. You can not have two int variables holding the value 3 and distinguish one from the other. They hold the same value. This is the same when the type is more complex.
Say I have a value type that has two fields, like
ValueType TwoFields {
int count;
double size;
}and say I have two variables
Twofields tF1 = new TwoFields(1,3.14) Twofields tF2 = new TwoFields(1,3.14)
I can not tell the variables tF1 and tF2 from other. If they were objects they would be equals to each other but not == to each other. In case of value types there is not == as they have no identity.
If TwoFields is immutable class I can not or should not write
TwoFields tF; ... tF.count++;
or some similar construct. But I still can write
TwoFields tF; ... tF = new TwoFields(tF.count+1, tF.size)
which leaves the original object intact. If TwoFields is a value type then either of the constructs, whichever is allowed, will create a new value.
Value types as arguments
How are value types passed as method argument then? Probably copying the value to the parameter variable. Possibly passing some reference. It is, however, up to the compiler (be it Java, or some other language). Why?
- Value types are usually small. At least they should be small. A huge value type looses the advantages that value types deliver but have the disadvantages.
- Value types are immutable so there is no problem copying them just like in case of primitives. They can be passed by value the same way as “everything in Java is passed by value”.
- They have no identity, there can be no references to them.
But this is not only about passing them as arguments. This is also how variables are assigned. Look at the code
Twofields tF1 = new TwoFields(1,3.14) Twofields tF2 = new TwoFields(1,3.14)
and compare it to
Twofields tF1 = new TwoFields(1,3.14) Twofields tF2 = tF1
If TwoFields is a value type there should be no difference between the two versions. They have to produce the same result (though may not through the same code when compiled). In this respect there is no real difference between argument passing and variable assignment. Values are copied even if the actual variables as bits contain some references to some memory locations where the values are stored.
Summary
As I started the article: value types need not be immutable. This is not something that the language designers decide. They are free to implement something that is mutable, but in that case it will not be value type. Value types are immutable.
| Reference: | Value types in Java: why should they be immutable? from our JCG partner Peter Verhas at the Java Deep blog. |
