Java finality

Tue Feb 8 08:25:00 GMT 2005

On Mon, 2005年02月07日 at 13:24 +0100, Jeroen Frijters wrote:
> Chris Burdess wrote:
> > This article
> > 
> > http://www.javaspecialists.co.za/archive/Issue096.html
> > 
> > explains how final fields can be modified, and that this behaviour is 
> > sanctioned by JSR 133. However, I find it rather disturbing. 
> [...]
> > What are other people's thoughts on this matter?
>> For constants it doesn't make much sense, but for blank final fields it
> makes perfect sense to me. Currently the serialization code is forced to
> use a special case of reflection to set final instance fields, but this
> change allows serialization to use the standard reflection mechanism.
> That's goodness in my book.

Note that this is also one of the only points where GNU Classpath and
libgcj still diverge on the ObjectStream code. In GNU Classpath we have
a special VM specific mechanism to set the (static final) fields. libgcj
just uses reflection on all fields. Whether this is a bug or a feature
in libgcj is to be decided seen the above discussion.
Note that if I read JSR 133 correctly changes to final fields are not
guaranteed to be seen by other threads ever after the object has been
constructed completely in the initiating thread. So it does look like it
is mostly a non-issue. It might appear to work, but shouldn't actually
be used at all except for the serialization code. It really looks like
JSR 133 made this exception solely to make serialization expressible in
java using the standard core classes. It should probably never been
relied on for any other code.
Cheers,
Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20050208/151be2aa/attachment.sig>