Comments on: You CAN Change Final Fields

By: Rémi Forax

Rémi Forax — Tue, 16 Oct 2007 20:26:51 +0000

For the record, you can change final field value using reflection with
1.1, 1.2, 1.5 and 1.6 VM not with 1.3 and 1.4,
this feature was disable after 1.3 and re-enable in 1.5,
following the recommandation of JSR 133 expert group (memory model).

Rémi

By: Eric Burke

Eric Burke — Tue, 16 Oct 2007 11:54:10 +0000

@qinxian none of these are bugs or broken. I never said that or even implied it. But people are apparently confused by my usage of the word “surprising”. Sigh.

I am thinking along the lines of topics mentioned in the book “Java(TM) Puzzlers: Traps, Pitfalls, and Corner Cases”. An entire book of perfectly legal, valid, non-buggy code that is surprising. If it were not surprising, the book wouldn’t have much of a reason to exist. For the record, other languages (say C++ or Ruby) have 10x the number of surprising, but legal, features.

By: qinxian

qinxian — Tue, 16 Oct 2007 10:44:40 +0000

Should we take it as a BUG of reflection function, which broken language spec? isn’t it?

By: Artur Biesiadowski

Artur Biesiadowski — Tue, 16 Oct 2007 09:24:43 +0000

Take a look at sun.misc.Unsafe class. If you have full privilages in jvm (like you need for setAccessible(true)), you can do a lot more funny things. With Unsafe class you can just modify any place in memory to any value – including change of class of the object, overwriting pointers to one object with pointers to noncompatible objects etc. Of course, crashing jvm is easiest of those options.

So, either speak about what is possibile in java in secured environment (like applets) – or don’t be surprised by anything, because with enough trickery, you can do whatever you want by direct memory manipulation. setAccessible(true) and setting final field is just a different form of direct memory manipulation, skipping normal accessibility rules (private, final, whatever).

By: Eric Burke

Eric Burke — Mon, 15 Oct 2007 12:26:29 +0000

@cm when I wrote one line of code that set a value, and the very next line of code I “retrieved” the value and saw the old data, I WAS SURPRISED.

By: cm

cm — Mon, 15 Oct 2007 11:40:34 +0000

This optimization is called inlining. The results are not surprising.
Try to decompile the class to see what actually happens.

Altough I agree you shouldn’t change final field via reflection.

By: Eric Burke

Eric Burke — Sun, 14 Oct 2007 18:46:58 +0000

@Carsten I show setSecurityManager(…) and discuss suppressAccessChecks in my previous post.

By: Carsten

Carsten — Sun, 14 Oct 2007 09:03:31 +0000

Note that setAccesible can throw a SecurityException – if there is is a SecurityManager you need to have the suppressAccessChecks permission. Thus no violation of access control, although very few apps run with a SecurityManager (virtually all Tomcat installations). Simply add to you main method: System.setSecurityManager(new SecurityManager()); and the hack will cease to work. Highly recommended if you write code that is supposed to run on an Appserver.

The optimization you have seen is technically not an optimization, final values of non-objects and String are allowed to be inlined by the compiler (you’ll find this somewhere in the JLS). If you use a Number object the first version of your code with set(caveman, Integer.valueOf(100)) will return 100.

By: It’s Just a Bunch of Stuff That Happens » Blog Archive » On the Violation of Java Access Control

Sun, 14 Oct 2007 01:22:07 +0000

[...] BPM: Not Even Comic-Worthy You CAN Change Final Fields » Oct [...]