The architects of Java have been ambivalent about the true meaning of "final". In the precursor to Java (called Oak), they had a "const" and a "final" modifier. The "const" variables were then changed to "final" in Java, just to confuse those trying to learn Java. In his humourous blog entry, Felipe goes one step further to suggest a "semifinal" modifier, which tells us: We are almost ready to make this final, just not quite yet! Fun reading, if only to look at some of the weird syntax structures that Java programmers come up with to avoid "lesser" Java programmers from messing up their code base. How often do you use "final" and would you find something like this useful? On another note, since JDK 1.5, you can modify a non-inlined final field using reflection. Who has done this in real projects?

good times.

In his humourous blog entry

Finally (no pun intended again :-) someone realized the blog was not to be taken seriously. I mean, the modifier could be useful, but it would not worth a change on the language... -- Felipe

It is very useful when writing your own serialization. This trick allows you to reconstruct objects with final fields.

I wonder how well this plays with DA/DU states.

That would be what would be needed: Supporting various semi-final fields using combinations with the "here be dragons" modifiers, volatile and transient. - volatile final int foo: foo might look final to you, but it might not be for the VM which is free to change it if necessary. - transient final int foo: foo will not keep its value when deserializing, and therefore is not final for all intents and purposes - only local purposes. - volatile transient final int foo: foo is only 20% final. I miss "private protected"... :) Or an explanation why "protected" is less protected than using the default access modifier...

I too happened to come across Felipe's post about semifinal. Although I didn't fully appreciate his motivation for it (I thought he was serious), I did post a comment about an earlier and more serious proposal for the introduction of "semifinal" keyword (or whatever combo of existing key words would provide the same connotation), which is as follows. Any feedback from you API developers? ================ I introduced a somewhat different notion of "semifinal" a while back. My motivation was also for the purpose of API development. However, the connotation is different... Semifinal on a method would allow non-package classes to call it, but not to override it. The motivation is defensive programming along the lines of what, I think, Joshua Block is urging in his book Effective Java. Adding semifinal to a method (or class) would prevent the API client (application developer) from overriding a critical method and possibly breaking the API base class, while still allowing the API host (API developer) to override the method. Thus, semifinal would work the same as final for an API client, but not for an API host (who presumably has package or private access). The main example cited in the following thread is to facilitate implementation of object wrappers, such as for wrapping a modifiable object with an unmodifiable wrapper, with both the target and wrapper classes provided by the API host and employing defensive programming through the use of the semifinal keyword. http://forums.java.net/jive/thread.jspa?messageID=14094&tstart=0