On virtual machines and expected behaviour

Ever tried running this on your ENTERPRISE VIRTUAL MACHINE?
Integer a = 1000;
 Integer b = 1000;
 System.out.println("a == b (1000 == 1000): " + (a == b));

 Integer aa = 100;
 Integer bb = 100;
 System.out.println("aa == bb (100 == 100): " + (aa == bb));
Guess what's the output, run it and report back.

>>18
Are you retarded? Auto-unboxing _does_ apply to every integer- the problem is as described in >>14. Now that we agree it is a caching issue; let me point out it's NOT sacrificing correctness. The spec states that "At run time, the result of == is true if the operand values are both null or both refer to the same object or array; otherwise, the result is false."

You would also be surprised how often some integers are boxed, and having to create a new Integer object for every one of them can over time create a significant enough performance hit to warrant this optimization. Either way, complaining over an optimizing compiler that conforms to the spec is kind of stupid.