• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java 5 final is final no more  RSS feed

 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Java 5 final is final no more,no more,no more

Apparently in JDK 1.5 final can be changed on reflection.



Is this allowable or a bug ?

From JSR 133:

� The semantics of final fields have been strengthened to allow for thread-safe immutatability without explicit synchronization. This may require steps such as store-store barriers at the end of constructors in which final fields are set.

In Java 5 you cannot change static final fields though( you could in Java 2).
[ October 08, 2004: Message edited by: Helen Thomas ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's been possible to set a final field for quite some time: I believe the concept of a "blank final" was introduced in JDK 1.1. The rule is that the final has to be initialized through every single possible construction path, or it's a compiler error. Once initialized, the final can't be changed again.
[ October 07, 2004: Message edited by: Ernest Friedman-Hill ]
 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ernest.
 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


This is the exception with 1.4.1 !

And this with Java 5: (Note the incorrect plane no: result)

[ October 09, 2004: Message edited by: Helen Thomas ]
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
it's always been the case that reflection if used unscrupulously (or carelessly) will ruin things like final and private access.

Nothing new there.
 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just find it odd that it was disallowed in 1.3 and 1.4 but it's allowed again for some probably valid reasons.

I suppose the spec must be read over and over again till Java 1.6
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This looks to me like a bug, plain and simple.

The attempt to modify the plane number and country silently fails, while the attempt to modify the person name and id succeeds? Either all of them should succeed, or there should be an exception thrown somewhere.

I don't think JSR-133 modifies the semantics of execution within a single thread, only between threads. Someone might have written a bug trying to implement it, though.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5059911 this is the expected behaviour for JDK 1.5.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tend to agree with Warren, except since the 5.0 documentation does explicitly allow for it, I suppose it's not technically a bug, just bad design. Compare Field in 1.4.2 to Field in 5.0 - the set() method has modified text. So OK, they specifically say that the behavior for nonblank final fields is undefined. Whatever - it may be undefined, but silent failure is a very poor behavior to implement. I'm also a bit surprised they'd simply revise the API this way - usually they seem extremely unwilling to break backward compatibility at the API level. Perhaps 5.0 had so many other changes, they decided to loosen up a bit in that area.
[ October 10, 2004: Message edited by: Jim Yingst ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
So OK, they specifically say that the behavior for nonblank final fields is undefined.


Ugh. That's a horrible precedent! In Java, everything's supposed to be defined, by design. Once that start with this, there goes the neighborhood...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
I'm also a bit surprised they'd simply revise the API this way - usually they seem extremely unwilling to break backward compatibility at the API level. Perhaps 5.0 had so many other changes, they decided to loosen up a bit in that area.


The way I understand the bug report, they changed the behaviour back to the way it was before 1.3 - possibly exactly *because* of backward compatibility issues?
 
R�mi Forax
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For me, they changed because in some case
you need final due to new memory model (JSR133)
but you need to allow serialisation too.

The only way to solve the problem is to
permit the change of final field using reflection
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I remember conversing on IRC with Neal M. Gafter (formerly of Sun Microsystems and J2SE 5.0 compiler developer) about this some time ago.

Here is an excerpt of the log:

Session Start: Thu May 13 08:55:42 2004

[omitted for brevity]

[10:42] <nmg1> One of the things in jsr133 is that you can share data using final fields without synchronization.
[10:42] <nmg1> For example, in immutable data structures.
[10:43] <nmg1> For example, java.lang.Integer has a private field for the int value.
[10:43] <nmg1> Before 1.5.0, the field wasn't final.
[10:43] <nmg1> But that wasn't correct, because the memory model doesn't guarantee cache consistency unless synchronized.
[10:44] <nmg1> So in theory - and in practice, it turns out - it would be possible for different threads to see the same java.lang.Integer in different states.
[10:44] <nmg1> So jsr133 recommended these fields be made final.
[10:44] <nmg1> OK, fine, a few months ago these fields were made final.
[10:45] <nmg1> Now recently one of Sun's web server produces tests with Tiger and it doesn't work.
[10:45] <nmg1> It turns out they have their own custom serialization scheme that depends on reflectively setting fields, like that in Integer.
[10:45] <nmg1> You would think that couldn't work for private fields - but they use Field.setAccessible.
[10:46] <nmg1> (Incidentally, String fields are being made final as well)
 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is Tiger's new memory model in anyway related to Apple's memory model which Sun are licensed to use?
[ October 12, 2004: Message edited by: Helen Thomas ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!