Re: JavaMemoryModel: Deserializing transient final fields (was: Will String be secure?)

From: Jeremy Manson (
Date: Thu Mar 04 2004 - 21:32:18 EST

> Sylvia wrote:
> > The readObject() method could be given special status if it's private and
> > not invoked from within the class. It could then be treated as if it were a
> > constructor, and be allowed to make the required assignment. Of have I
> > missed the point?
> Because the calling context of readObject required here is not a
> static, syntactic property, the final-field set would need to be done
> using reflection, so it can be dynamically checked.

Doug -

This may be something obvious, but I can't think of it. What is the use
case for this that couldn't be alternately expressed without too much
difficulty with Sylvia's proposed answer?

To take a step back, this seems to me to be one of a wider set of problems
with construction in general. For "the next programming language"
(whatever that might be), I've often thought that there should be a
constructor that takes an ObjectInputStream as its parameter, and allows
you to deserialize directly into the object being constructed.

Whatever else the effect, it would allow final field semantics to be much
more simple.

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:59 EDT