aspose file tools*
The moose likes Java in General and the fly likes equals() and == how they related by given example Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "equals() and == how they related by given example" Watch "equals() and == how they related by given example" New topic
Author

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

bikasit babu
Greenhorn

Joined: Mar 29, 2012
Posts: 28
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

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

Joined: Aug 07, 2007
Posts: 1950
    
  28
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
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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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


Base type? You mean primitives?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13884
    
  10

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

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36579
    
  16
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
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

Jeff Verdegan wrote:Base type? You mean primitives?

Yup
bikasit babu
Greenhorn

Joined: Mar 29, 2012
Posts: 28
thank you guys for your reply .
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7081
    
  16

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


Isn't it funny how there's always time and money enough to do it WRONG?
Artlicles by Winston can be found here
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
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
Ranch Hand

Joined: Mar 05, 2008
Posts: 2970
    
    9
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
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
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
Ranch Hand

Joined: Mar 05, 2008
Posts: 2970
    
    9
The Java SE 6 I have here on my Mac still uses the property:
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
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 :



and

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
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
Sheriff

Joined: Oct 27, 2005
Posts: 19556
    
  16

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


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: equals() and == how they related by given example
 
Similar Threads
KB 235
Boxing, == and equals
how is this possible please explain
difference between != or ==
how is this possible please explain