RE: Object serialization and final fields

[David Holmes]

Mark Wielaard wrote:
> BTW. Note to VM/Compiler implementers!
> --------------------------------------
> We discussed "final" fields a bit more on irc.
> We came to the conclusion the the VM spec authors and the JLS spec
> authors have a different interpretation of "final".
> According to the VM spec a final field is non-private read-only, but
> rewritable by the Class defining the field.
> According the the JLS spec a final field is single assignable (in a
> [static] constructor method).
> JNI doesn't seem to define precisely what/how final fields can change.
> The above patch depends on the fact that in practice JNI setXField() can
> be used to set a final field (this was already the case for the
> System.setIn()/setOut()/setError() methods).
>
> The following bug reports are also interesting:
>
> http://developer.java.sun.com/developer/bugParade/bugs/4027808.html
> Synopsis: [JNI] SetObjectField modifies a final field value
> State: Closed, will not be fixed
> Evaluation: JNI does not guard against illegal access to objects [...].
>
> http://developer.java.sun.com/developer/bugParade/bugs/4115974.html
> Synopsis: Need to be able to tell JIT not to optimize certain finals.
> State: Closed, will not be fixed
> Evaluation: These are the only thing which should ever behave this way,
> so there's no need for a special interface for this.  The JIT just needs
> to handle these specially.
>
> http://developer.java.sun.com/developer/bugParade/bugs/4174797.html
> Synopsis: Serialization should not use reflection to set final fields
> State: Closed, fixed
> Evaluation: [...] Serialization needs to use JNI Set<type>Field Routines
> to set fields, instead of Field.set*(). [...]
>
> All this seems a bit unfortunate since it basically means that a runtime
> cannot optimize final field access since they can always be changed
> through JNI and this "feature" is at least necessary for both
> System.setIn/Out/Err() and reflection.

These issues may be addressed in the near future - though it is a bit of a
mess. The new Java Memory Model basically allows all the optimisations you
want and says that native modification of final fields, beyond use of
SetIn/Out/Err, need not cause a change by one thread to become visible in
another. In other words any application using this is on its own. There are
also special rules for handling the deserialisation issue with finals.

See http://www.cs.umd.edu/~pugh/java/memoryModel for details.

David Holmes