Sylvia,
That also leaves unresolved the issue of what to do when you are
creating your own sub-class of java.io.ObjectInputStream, for
serializing classes with no readObject / readExternal. The same
functionality needs to be available there. If Doug's suggestion
is not needed in one case out of three, but is in the other two
cases, it is therefore still needed :-)
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Sylvia Else
> Sent: Friday, 5 March 2004 5:44 p.m.
> To: javamemorymodel@cs.umd.edu
> Subject: Re: JavaMemoryModel: Deserializing transient final fields (was:
> Will String be secure?)
>
>
> At 07:56 AM 4/03/2004 -0500, Doug Lea wrote:
>
> >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.
>
> What I had in mind was that constructors cause no particular
> difficulty in
> this respect, so why not elevate readObject to the status of a
> constructor
> in the special circumstance where it could only be called by reflection
> either from within the class (an odd concept) or from elsewhere
> with access
> controls bypassed. This situation is recognisable both by javac,
> and by the
> JIT.
>
> It's rather ad-hoc, but the alternative of requiring transient
> final fields
> to be set by reflection seems so heavyweight (and cumbersome to
> code) that
> programmers would avoid making transient fields final except
> where this was
> necessary for security (and the programmer understood the
> issue!). I would
> prefer the situation where people made fields final unless they needed to
> be set more than once.
>
> Evan, regarding readExternal and writeExternal, I imagine your concern is
> that they don't fit into this model because they obviously have to be
> public (and so could be called from anywhere at any time), and
> constructors
> (the no-arg public ones) have already been called. I suppose Doug's
> reflection approach would have to be used here.
>
> Sylvia.
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:59 EDT