Re: JavaMemoryModel: Legality of native code changing final field s

From: David Smiley (
Date: Tue Jun 12 2001 - 17:26:09 EDT

----- Original Message -----
From: "Bill Pugh" <>
To: <>
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

> * 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 -

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