Evan,
> Regarding the scope of JMM revision, in:
>
> http://www.jcp.org/en/jsr/detail?id=133
>
> section 2.5, we see:
> Immutable objects (objects whose fields are only set in their
> constructor)
The notion of "immutability" that JSR-133 is concerned with is only
that defined by the use of final fields. Any proposals for language
extensions to support a more elaborate notion of immutability - as was
being proposed - is beyond the scope of JSR-133.
> In regard to serialization of value types with RMI, the notion of
> immutability is of some interest, in particular because the JDK
> provides no standard way for custom-coded serialization classes
> to set final fields
I agree - this is a major flaw in the language/library integration.
> (2) If an object is created without calling any constructor, its
> final fields could remain unfrozen until they are explicitly
> frozen, thereby allowing setting via
java.lang.reflect.Field.set.
My reading of the spec indicates that non-bytecode assignments to
final fields, such as those done via serialization or JNI, must
performs a "freeze" action after that assignment. In the absence of
such a freeze then things would be similar to what you suggest. Though
in the absence of a freeze API the only solution is to have
deserialization and JNI assignment issue the freeze themselves - hence
negating the ability to set the field reflectively as it would always
be frozen. Further, as indicated in the spec, any sharing of such an
object with "thawed" fields would typically render the final field
semantics useless for that object.
Though JSR-133 has to accommodate the notion of "freezing" of final
fields to deal with deserialization/JNI, it is again beyond scope for
it to remedy the real problem (though such a remedy might make it
easier to specify the JMM). I can see scope for a future JSR that
tries to address the problem of integrating final field usage and
serialization customisation, but for now it doesn't exist. I think the
current specification on freezing of final fields is about as much as
can be specified at this time.
Even if there was agreement now that something should be done, it
simply can't be done given the stage of the process that JSR-133 is
at, and given the constraints on getting any JSR's adopted into the
1.5 Tiger release.
Cheers,
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:52 EDT