1 = 40 ?

Question

Hello,
First let me say sorry if this has been raised previously, I am new to generics.
Consider this code:import java.lang.reflect.*;
class GenericTest {
     public static void main(String[] args) throws Throwable {
          int m = 1;
          System.out.println("before:\t" + m);
          a(m);
          System.out.println("after:\t" + m);
          System.out.println("\r\nHopefully everything is back to normal now: ");
          b(m);
     public static void a(Integer k) throws Throwable {
          Field f = Integer.class.getDeclaredField("value");
          f.setAccessible(true);
          f.setInt(k, 40);
          System.out.println("during:\t" + k);
     public static void b(Integer k) {
          System.out.println("second:\t" + k);
} We can note a very strange result from this code.
With my compiler, version:java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b51)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b51, mixed mode, sharing) The result is:before: 1
during: 40
after:  1
Hopefully everything is back to normal now:
second: 40 so we have changed the value of 1 to 40 !!
Surely this is terrible! It is because, it seems, that generics only creates 1 new integer
object to carry out the generic call right ? and then-on refers to that object. However the
"a" method completely breaks this system as for now on in this program any integer "1"'s
will actually be "40" integers.
Is this expected behaviour ?

Answer 1

I am not enough a language lawyer to know if you
should be allowed to break immutability like
that, but you did it.Its a matter of security policy. That code would never work in an unsigned applet or any other environment where a security manager happened to be inplace.
Now, it might be worth asking if the major application server vendors and the JSP servers like Tomcat are running with a security manager enabled or not! If I were an ISP hosting 3rd party sites I might worry somewhat.
Now, a reasonable question is, assuming no security manager, does this code allow us to do anything we couldn't do in 1.4.
Clearly in 1.4 we could contruct an Integer, pass it to some library function then use reflection to change the int value of the Integer at an opportune time to cause trouble.
If the library function copies the Integer ... ie
public void someLibraryFunction(Integer i) {
     //joshua bloch recommends defensive copies
     //*before* assertions, for reasons that should now
     //be obvious
    Integer i = new Integer(i.intValue());
    assert: i > 0 ...
}then we'll see that the code is still safe, because new Integer always returns a new Integer object, not a copy from the pool.
The only cases I can see where an attack would be possible:
1 ) the security manager is off AND
2) an API takes Integer argumentsd and does not make defensive copies OR
3) an API takes int arguments and boxes them using the new Integer.valueOf(int) method.
As Integer.valueOf(int) is a new method in 5.0, it follows that there is no code currently using it.
Advice would be: if you're writing security sensetive code, and you need to either accept Integer arguments or box int arguments as Integers, always make defensive copies and always use "new Integer()" to make your boxes.
Certainly one can do evil things from a maintainability perspective with reflection. So, "Don't do that!" :)
From a security perspective I think it depends: one wouldn't generally make defensive copies of immutable objects, but as we can see, if one is truly paranoid, one probably should.
This also neatly demonstrates security is a property that emerges from the behaviour of the system as a whole: your code may be fine, but if the security manager (and the bytecode verifier) is not enabled for a given instance of your program, all bets are off. You have to look at the big picture.