What if someone access that field?
As I understand, the current Thread can cache the
first value seen, and remember it "forever".
For example:
final int myField;
private void readObject(java.io.ObjectInputStream
in) throws IOException, ClassNotFoundException {
int x = myField;
in.defaultReadObject();
int y = myField;
try {
getClass().getField("myField").setInt(this, 12);
} catch (Exception e) {
e.printStackTrace();
}
int z = myField;
System.out.println("x = " + x);
System.out.println("y = " + y);
System.out.println("z = " + z);
}
Doron.
--- Doug Lea <dl@cs.oswego.edu> wrote:
>
> 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
=====
Doron Rajwan, mailto:doron@rajwan.org
-------------------------------
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