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.
:-(
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.
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.
How do people feel about the following?
* When constructing an object through JNI, you can ask for a
"partially constructed object".
* 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.
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.
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.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:31 EDT