> > 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?
That is the idea, but it would probably have to be a new JNI call.
For the simple case of an object that has no superclass other than
Object and implements Serializable, the deserialization code:
* Allocates an object with all fields set to the default value
* Sets the non-transient fields of the object using JNI calls.
* calls readObject (if defined) to set the transient fields and allow other
custom deserialization
* if defined, calls readResolve() to allow a substitute object to be used
instead
No constructor ever gets called. So at some point, probably after the
call to readObject() and before the call to readResolve(), we make
the JNI call that "completes" the object.
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:32 EDT