At 11:54 AM -0700 8/9/01, Joshua Bloch wrote:
>Bill,
>
>> If all fields of String are final, we get the required semantics.
>> This will require that the existing implementation of String be
>> changed so that all of the fields are marked as final, but this
>> should not be a problem.
>
> This is a problem. The hashCode of a String is calculate the first time
>hashCode() in invoked. More generally, immutable classes must be able to
>support lazily evaluated computations.
>
> Josh
OK, this is enough to kill my simple example and to motivate the more
complicated and subtle semantics we are expecting to have.
Although I started off talking about immutable objects, the semantics
we expect to have doesn't discuss them. Rather, it just discusses the
special properties of final fields.
These properties include:
Any thread is guaranteed to see the correct value for the final field,
even if their was a race
- furthermore, if that value is a reference, they are guaranteed to
see all writes done in the constructor when reading the object/array
referenced through the value read.
- for example, for String objects, if you read the value field, you
not only see the correct value for the reference to the char[], you
also see the correct contents of the char[].
- the semantics are such that this will also work for a reference to
a multidimensional array, or a reference to an array of mutable
objects (assuming those objects are not mutated once the
original object is constructed).
Reads of non-final fields don't get special semantics. So the
hashCode function will need to check the hashCode is see if it is
zero each time through the loop (I presume we don't care about the
fact that if the computed hash turns out by chance to be zero, we
will recompute it each time).
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:34 EDT