Integer i2 = 1000;
if(i1 != i2)
here inthis case output willbe both Different Object and Meaningfully Equal
Integer i3 = 10;
Integer i4 = 10;
if(i3 == i4)
System.out.println("Meaning fully same");
here in this case output will come same Object and Meaning fully same why
Why both the cases contradict?
1. == tests whether two reference values are the same--that is, both references point to the same object, or both are null.
2. equals() does whatever the class author writes it to do, but what it is supposed to do (and does do for relevant core API classes like Integer, String, Date, etc.) is determine whether two objects are semantically equal as per the appropriate definition of "equal" for that class.
3. If you don't override equals(), it inherits from Object's equals(), which just uses ==.
4. String and the integer wrapper classes (Integer, etc.) have constant pools, with the end result that sometimes == will evaluate to true even though you might think you have two distinct objects.
Using those facts, you should be able to determine what's going on in your code.
If you change your code to explicitly create Integer objects ie
You will now get the result you expected.
Basically don't compare objects using == unless you have a very very good reason to (and there aren't many) and you really understand what you are doing.
Tony Docherty wrote:Basically don't compare objects using == unless you have a very very good reason to (and there aren't many) and you really understand what you are doing.
And further to that point, have a look at this page.
Campbell Ritchie wrote:But many of those posts will suggest that Integer i = 1000; is not cached. This is not quite true. If you look in the documentation, it says values between -128 and +127 are cached, and maybe more. The ideal is for all values to be cached. You might change implementation and find you now have an implementation which caches -32768…+32767, and the behaviour of your example with 1000 changes.
The "maybe more" part is frankly enlightening, thank you for pointing it out. Can you also please tell me where I can see the actual values/range covered(atleast in the standard SE 7 implementation).
Mike Simmons wrote:You could look at the source code for java.lang.Integer. The static nested class Integer.IntegerCache encapsulates the functionality you're asking about. You can see where it looks up the system property java.lang.Integer.IntegerCache.high, if set, and takes the max of that or 127 to determine the size of the cache.
Thanks Mike. I checked it on SE 6 which had the code for IntegerCache, but it did not have reference to a "high" property(this must've been introduced in SE 7). The range in SE 6 is from -128 to (127+1).
1) The version that I have is - jdk1.6.0_06 which has the src.zip source file.
2) Integer.class header :
* @author Lee Boynton
* @author Arthur van Hoff
* @author Josh Bloch
* @version 1.92, 04/07/06
* @since JDK1.0
3) According to Wikipedia, Java SE 6 was released in December 11, 2006, but the date in the header info is incongruent.
4) The code pertaining to IntegerCache :