equals() and == how they related by given example

[bikasit babu]

Integer i1= 1000;
Integer i2 = 1000;
if(i1 != i2)
{
System.out.println("different Object");
}
if(i1.equals(i2))
{
Sytem.out.println("Meaningfully same");
)
here inthis case output willbe both Different Object and Meaningfully Equal
BUT
Integer i3 = 10;
Integer i4 = 10;
if(i3 == i4)
{Sytem.out.println("same Object");
}
if(i3.equals(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?

[Jeff Verdegan]

I don't understand your question, but here's a summary of == and equals().

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.

[Seetharaman Venkatasamy]

base type? yes you can use ==, != etc..
is that object? hmm.. better always(may be situation of 92%) use equals...

[Tony Docherty]

The reason you are getting this apparent anomaly is down to the constant pools as explained by Jeff in point 4 of his post.

If you change your code to explicitly create Integer objects ie

    Integer i3 = new Integer(10);
    Integer i4 = new Integer(10);
    if(i3 == i4)
    {System.out.println("same Object");
    }
    if(i3.equals(i4))
    {
    System.out.println("Meaning fully same");
    }

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.

[Jeff Verdegan]

Seetharaman Venkatasamy wrote:base type? yes you can use ==

Base type? You mean primitives?

[Jesper de Jong]

This exact question has been asked and discussed before:

http://www.coderanch.com/t/581328/java/java/classes-Wrapper
http://www.coderanch.com/t/542018/java/java/related-Wrapping
http://www.coderanch.com/t/538649/java/java/Wrapper-Objects
http://www.coderanch.com/t/527984/java/java/equals
http://www.coderanch.com/t/517958/java/java/when-boxing-unboxing-used
http://www.coderanch.com/t/497029/java/java/possible-please-explain
http://www.coderanch.com/t/496079/java/java/Query-boxing-why-both-works
http://www.coderanch.com/t/491902/java/java/equals-Please-help

[Campbell Ritchie]

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.

[Seetharaman Venkatasamy]

Jeff Verdegan wrote:Base type? You mean primitives?

Yup

[bikasit babu]

thank you guys for your reply .

[Winston Gutkowski]

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.

Winston

[Praveen Kumar M K]

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]

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.

[Praveen Kumar M K]

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).

Thanks again,
Praveen.

[Mike Simmons]

The Java SE 6 I have here on my Mac still uses the property:

    // value of java.lang.Integer.IntegerCache.high property (obtained during VM init)
    private static String integerCacheHighPropValue;

    static void getAndRemoveCacheProperties() {
        if (!sun.misc.VM.isBooted()) {
            Properties props = System.getProperties();
            integerCacheHighPropValue =
                (String)props.remove("java.lang.Integer.IntegerCache.high");
            if (integerCacheHighPropValue != null)
                System.setProperties(props);  // remove from system props
        }
    }

[Praveen Kumar M K]

Strange, here's what I've got.

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 :

private static class IntegerCache {
	private IntegerCache(){}

	static final Integer cache[] = new Integer[-(-128) + 127 + 1];

	static {
	    for(int i = 0; i < cache.length; i++)
		cache[i] = new Integer(i - 128);
	}
    }

and

public static Integer valueOf(int i) {
	final int offset = 128;
	if (i >= -128 && i <= 127) { // must cache 
	    return IntegerCache.cache[i + offset];
	}
        return new Integer(i);
    }

[Jeff Verdegan]

Praveen Kumar M K wrote:
* @version 1.92, 04/07/06
3) According to Wikipedia, Java SE 6 was released in December 11, 2006, but the date in the header info is incongruent.

How so? Code checked in April 7, '06, released 8 months later. Seems reasonable to me.

[Praveen Kumar M K]

Jeff Verdegan wrote:How so? Code checked in April 7, '06, released 8 months later. Seems reasonable to me.

Yes, please disregard that comment! That was a result of an unreasonable brain wave from my side

[Rob Spoor]

The high property was introduced in one of the updates. It wasn't available in the first few releases of Jave 6.