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.

>>31
The specification is perfectly consistent. The == operator will always compare reference values for objects. That is about as consistent as you can get; and in fact if it specified "[==] returns true if the integers are equal" this would be breaking backwards compatibility which was exactly my point to begin with.

The only way it wouldn't break would be if it specified two equal Integer objects must always have the same reference; and this is exactly what I was pointing out was impractical in >>25.

As for the -127 to 128 issue. This can't be resolved now either as it would break compatibility also, so it's stuck as is. If you are arguing it shouldn't have been done in the first place for consistency- I would have to disagree.

The very nature of the comparison is inconsistent. The spec makes no provisions for what reference locations should be allocated by the VM and in general (as mentioned above) there is no way to tell whether two Integers are ==. You are esentially saying we should make the behavior consistent in its inconsistency- what the hell?

>>32
Show me where in the spec it states a == b returns false. You are clearly an idiot and should be quiet.