Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
bikasit babu
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
base type? yes you can use ==, != etc..
is that object? hmm.. better always(may be situation of 92%) use equals...
 
Tony Docherty
Bartender
Posts: 2957
59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seetharaman Venkatasamy wrote:base type? yes you can use ==


Base type? You mean primitives?
 
Campbell Ritchie
Sheriff
Pie
Posts: 48949
60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:Base type? You mean primitives?

Yup
 
bikasit babu
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you guys for your reply .
 
Winston Gutkowski
Bartender
Pie
Posts: 10417
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 256
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3076
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 256
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3076
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Java SE 6 I have here on my Mac still uses the property:
 
Praveen Kumar M K
Ranch Hand
Posts: 256
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 256
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 20527
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The high property was introduced in one of the updates. It wasn't available in the first few releases of Jave 6.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic