----- Original Message -----
From: "Bill Pugh" <pugh@cs.umd.edu>
To: <JavaMemoryModel@cs.umd.edu>
Sent: Tuesday, June 12, 2001 2:24 PM
Subject: Re: JavaMemoryModel: Legality of native code changing final field s
> At 9:37 AM -0400 6/12/01, David Smiley wrote:
> >I think there shouldn't be a problem with JNI creating some object and
> >setting its (possibly final) fields, and then "giving it to the VM" since
> >the VM has never seen it before and has yet to make any assumptions about
> >the final fields.
>
> :-(
Why the frown?
> I spent some time looking at the current implementation of
> readObject, and it uses JNI to set all fields, including.
> Unfortunately, it accesses the object from the Java source/VM level
> after the object has been allocated, but before the final fields have
> been set.
Hmmm, that looks like a poor way to do it in light of our JMM issues here.
I figured it was actually done this way.
> Our whole treatment of final fields had been based on the idea that
> there was a point at which the object was "constructed" and the final
> fields "frozen". Unfortunately, for serialization, there doesn't seem
> to be any such moment.
Then change the serialization implementation so that there is such a moment;
is that out of the question?
>
> How do people feel about the following?
>
> * When constructing an object through JNI, you can ask for a
> "partially constructed object".
Heck, why not also say that an object whose constructor hasn't finished is
"partially constructed"? That way you could say a final field can only be
set for "partially constructed" objects--which is a nice definition. And
then don't make exception for this rule, even for JNI, except for
System.out/in/err.
> * It is legal to use JNI to change any field, including final fields,
> of "partially constructed objects".
>
> * There is a JNI call that "finishes" construction of a partially
> constructed object.
>
> * After construction of an object has been "finished", using JNI to change
> a final field of that object is undefined and can corrupt your JVM.
--on that last point: or just disallow mutating final fields altogether once
you have a "finished" object.
> This would require changing about 10 lines of the deserialization code.
>
> Adding new JNI methods and rewriting the deserialization code is more
> of an impact than I wanted, but I'm not sure how to define the
> semantics otherwise.
Adding onto what I said about an object being "partially constructed" while
the constructor is still going... you could make serialization be a special
constructor. After all, the actual constructor isn't used during
serialization. This way is also nice because other than a "special
serialization constructor", there are no other serialization issues. That
would be more elegant, I think.
I should drop off this thread now since I don't know enough about JNI.
> An alternative would be to define additional reflection methods that
> could be used to implement deserialization. These methods would need
> to have special
> semantics in the memory model as well.
mmm, ick.
-- Dave
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT