Sylvia,
Could you please elaborate, and describe how your suggestion
would apply to readObject + readExternal + user-defined subclasses
of java.io.ObjectInputStream (needed if you are implementing RMI-IIOP,
for example).
Thanks.
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Sylvia Else
> Sent: Thursday, 4 March 2004 3:32 p.m.
> To: javamemorymodel@cs.umd.edu
> Subject: Re: JavaMemoryModel: Will String be secure?
>
>
> At 07:19 AM 3/03/2004 -0500, Doug Lea wrote:
>
> >While it seems too late to do anything about this for JDK1.5.0, it is
> >still worth thinking about how to safely allow reestablishing
> >transient final fields during deserialization. Otherwise people will
> >still not use final when they otherwise should.
> >
> >The only idea I've ever had about this always seemed too ugly, messy,
> >and slow to actually carry out, but now seems more plausible:
> >
> > Change java.lang.reflect support to allow a reflective Field.setX (X =
> > Short, Float, etc) for a final field of an object currently being
> > deserialized.
> >
> >In principle, this seems possible: the reflection and security
> >mechanisms can detect if the write can be safely allowed, and if it
> >is, the write can be done using "volatile" semantics, which would
> >suffice wrt JMM guarantees.
> >
> >Can anyone think of alternatives?
>
> 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?
>
> 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