[concurrency-interest] Concurrent Serialization Pattern

David Holmes dcholmes at optusnet.com.au
Fri Sep 15 02:29:55 EDT 2006


Well not quite. If the final field is a compile-time constant then the
bytecode doesn't contain any field access expressions it simply uses the
compile-time constant value directly. The actual
serialization/deserialization is unaffected. 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.

David Holmes

> -----Original Message-----
> From: crazyboblee at gmail.com [mailto:crazyboblee at gmail.com]On Behalf Of
> Bob Lee
> Sent: Friday, 15 September 2006 4:17 PM
> To: dholmes at ieee.org
> Cc: Kevin Condon; concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Concurrent Serialization Pattern
>
>
> It only works for constants. :(
>
> On 9/14/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> > Kevin,
> >
> > > I didn't realize that the final sematics had
> > > precedence over the transient qualifier, so I incorrectly thought that
> > > lock would have the default null value after deserialization.
> >
> > 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.
> >
> > Something seems amiss here.
> >
> > David Holmes
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >



More information about the Concurrency-interest mailing list