I can finally answer...
> B. "[...] if the fields of the String class were not final [...]"
> This suggests that these fields are final; however, they are not.
The relevant fields of String and other immutable classes in
java.lang, such as Integer are now declared as final in JDK1.5.0
source. I think they will appear this way in beta2. (Even though these
changes are due to JSR133, I helped coordinate them via JSR166
connections, since JSR133 does not otherwise deal with APIs or
implementations.)
As a follow up to this, some Sun JDK developers have been looking into
adding "final" when possible in other existing JDK classes. They have
been running into the problem that there is no way to restore a
"transient final" field inside a readObject method. As we've
discussed, there is usually some way to design around this limitation
when defining a new class. But you normally can't apply these
workarounds to existing Serializable classes because they change the
serialization structure (and usually other code as well). There is a
way for JDK code to cheat code by using priviliged internal APIs
inside JDK that can set final fields, but JDK developers are, and
should be, reluctant to bypass normal language rules here.
While it seems too late to do anything about this for JDK1.5.0, it is
still worth thinking about how to safely allow reestablishing
transient final fields during deserialization. Otherwise people will
still not use final when they otherwise should.
The only idea I've ever had about this always seemed too ugly, messy,
and slow to actually carry out, but now seems more plausible:
Change java.lang.reflect support to allow a reflective Field.setX (X =
Short, Float, etc) for a final field of an object currently being
deserialized.
In principle, this seems possible: the reflection and security
mechanisms can detect if the write can be safely allowed, and if it
is, the write can be done using "volatile" semantics, which would
suffice wrt JMM guarantees.
Can anyone think of alternatives?
-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:58 EDT