It was my informal understanding that to allow for deserialization of
objects with final fields, the reflection setAccessible(true) method would
be allowed to succeed if invoked from readObject, so that a final field
could be set to its correct value using Field.set.
Other attempts to set a final field via reflection would fail - as in JDK
1.4.*.
Instead of this nice clean model, that fixed serialization and final fields,
it seems that somewhere along the way things changed. What we actually have
is this:
You can set a final field using Field.set if:
a) the field is non-static; and
b) setAccessible(true) succeeds
This has two undesirable consequences:
a) with no security manager, or the right permission, final fields can be
set arbitrarily. My understanding is that the JMM does not require the
values of such final field changes to be seen, unless set from readObject
(or more generally a 'final field safe context'). So this is just a recipe
for creating a mess.
b) Much worse is the fact that with a security manager installed custom
deserialization will fail if it tries to set a final field, unless the
suppressAccessChecks permission is granted.
This makes no sense. The whole point was that readObject was supposed to get
special dispensation to set final fields WITHOUT needing special security
permission!
What we have now makes no sense. We didn't fix serialization and final
fields (because explicit permission is needed), and we re-opened a door that
was closed in 1.4 because setting final fields via reflection was deemed to
be bad.
How did we end up here? ???
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:01:09 EDT