JavaMemoryModel: Re: Serialization and final fields - what happened?

From: Doug Lea (dl@cs.oswego.edu)
Date: Thu Mar 03 2005 - 06:42:33 EST


>
> You can set a final field using Field.set if:
> a) the field is non-static; and
> b) setAccessible(true) succeeds
>

It is a good time to re-raise this issue. Thanks for doing so!

The current state of affairs is not too nice. It was an ad-hoc
solution we reached after finding that the JSR133-driven changes to
core immutable objects (java.lang.Integer etc) to declare all fields
final broke just about all J2EE middleware frameworks. These do
pseudo-deserialization by directly setting fields, but only after
doing setAccessible. (You can correctly argue that this code was
never guaranteed to work in the first place so it was OK to break it,
but that argument won't get you very far in practice!) The current
rules exploit the fact that all of these usages happen to work in the
intended way (i.e., without compromising main finalness properties)
and yet maintains compatibility. In the absence of any other readily
implementable solution, the only alternative would have been to roll
back the "final" declarations, which would have made JSR133 rules not
apply to the most commonly used immutable objects in Java, which would
have been much worse.

It would be great to redo this right.

In most senses, the best solution would be to allow any class to
reflectively set final fields during deserialization but not
otherwise.

But among the problems with this is that a lot of code out there does
some kind of pseudo-deserialization (from database records, XML,
etc). So you can't tie the rules to deserialization proper. So there
has to be some more general escape hatch. Probably something tied to
the current setAccessible rule, but somehow less general.

Does anyone have any good ideas about this?

-Doug
-------------------------------
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