[concurrency-interest] Concurrent Serialization Pattern

Kevin Condon conivek at gmail.com
Fri Sep 15 09:54:00 EDT 2006


David,

On 9/15/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> As a test, serialize an
> instance when the constant has value A, recompile the class with the
> constant set to B, read the old serialized instance back in and "access" the
> final field - you will see B.

That was exactly the test I used when I empirically discovered the
unexpected behavior.

> > > According to my reading of the serialization spec it *should*
> > have a null
> > > value. transient fields don't get serialized, unless you custom
> > serialize
> > > them. So a transient final field should have its default
> > initialized value
> > > when readObject is invoked.

I'm not entirely content with empirical discovery for understanding
JMM issues, and the serialization spec *does* seem to give an
expectation of seeing the default value for the transient final field:
 "The values of every field of the object whether transient or not,
static or not are set to the default value for the fields type"  (sec
3.4).  Though it doesn't explicitly mention "final" fields.  Since
"Fields declared as transient or static are ignored by the
deserialization process" according to the ObjectInputStream javadoc, I
guess it makes sense for "ignored" to mean that transient fields are
left in the "completely initialized" state that Class.newInstance()
leaves them in (JLS 17.5).  So the guarantee for never seeing the
transient final field's default value is provided by JLS 16 and 17.5.
Maybe an explicit statement about transient final fields would help in
the serialization spec and in the ObjectInputStream API javadoc?

I wonder why there's such an expectation that transient final fields
would have their default value after deserializing.  Do older
compilers or JVMs behave differently?  Or is it just the clarity of
the docs, esp. the serialization spec sec 3.4?

Regards,
Kevin


More information about the Concurrency-interest mailing list