my dog learned polymorphism*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes == and != in Integer literals Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "== and != in Integer literals" Watch "== and != in Integer literals" New topic
Author

== and != in Integer literals

Ilakya Mukunth
Ranch Hand

Joined: Mar 13, 2012
Posts: 56
1. Integer i1 = 1000;
2. Integer i2 = 1000;
3. if(i1 != i2) System.out.println("different objects");
4. if(i1 == i2) System.out.println("same object-1");

5. Integer i3 = 10;
6. Integer i4 = 10;
7. if(i4 == i3) System.out.println("same object-2");

Output
====
$ java Samples.Equals1
different objects
same object-2

I do not understand the output. All i1,i2,i3 and i4 variables are assigned with literals. Then why should only i3 and i4 are == and why not i1 == i2?
Can anyone explain me?

If you change the value of i1=100 and i2=100, the output will be
$ java Samples.Equals1
same object-1
same object-2

I do not understand this logic...
Deepa Sobin
Greenhorn

Joined: May 22, 2011
Posts: 9
Hi Ilakya,

As i1 and i2 are Integer objects, == does not compare their values. To compare if the two instances are meaningfully equivalent, you need to use the equals() method.

In order to save memory, two instances of the wrapper objects (created through boxing), will always be == when their
primitive values are the same, for Short and Integer from -128 to 127 (refer K&B page 246).
Vishal Baid
Ranch Hand

Joined: Jul 18, 2012
Posts: 36
Deepa Sobin wrote:Hi Ilakya,

As i1 and i2 are Integer objects, == does not compare their values. To compare if the two instances are meaningfully equivalent, you need to use the equals() method.

In order to save memory, two instances of the wrapper objects (created through boxing), will always be == when their
primitive values are the same, for Short and Integer from -128 to 127 (refer K&B page 246).


Thanks Deepa for reply I was having the same problem. I was doing google.
Danjel Nyberg
Greenhorn

Joined: Sep 12, 2012
Posts: 15

Same goes for strings...

String a = "Test";
String b = "Test";
System.out.println(a==b); //prints true
String c = new String("Test");
System.out.println(a==c); //prints false

In this case since a and b are created via string litherals they point to the same object, but since c is created with new keyword this will be another object and therefore a is not the same as c

This is wierd in so many ways. In all normal cases you allways compare objects with equals method only...

/Danjel
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1666
    
    7

Also, have a look at AvoidTheEqualityOperator.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Ilakya Mukunth
Ranch Hand

Joined: Mar 13, 2012
Posts: 56
Danjel Nyberg wrote:Same goes for strings...

String a = "Test";
String b = "Test";
System.out.println(a==b); //prints true
String c = new String("Test");
System.out.println(a==c); //prints false

In this case since a and b are created via string litherals they point to the same object, but since c is created with new keyword this will be another object and therefore a is not the same as c

This is wierd in so many ways. In all normal cases you allways compare objects with equals method only...

/Danjel


I understand this example well. But according to my code snippet, all the Integer reference variables are assigned the literal values.
Ilakya Mukunth
Ranch Hand

Joined: Mar 13, 2012
Posts: 56
Vishal Baid wrote:
Deepa Sobin wrote:Hi Ilakya,

As i1 and i2 are Integer objects, == does not compare their values. To compare if the two instances are meaningfully equivalent, you need to use the equals() method.

In order to save memory, two instances of the wrapper objects (created through boxing), will always be == when their primitive values are the same, for Short and Integer from -128 to 127 (refer K&B page 246).

If you change the value of i1 and i2 to 100, it syas i1 == i2. but in case of i1=i2=1000, they are not i1 == i2

Thanks Deepa for reply I was having the same problem. I was doing google.
Rameshwar Soni
Ranch Hand

Joined: Feb 03, 2011
Posts: 247
Just have a look at this thread to clear your doubts.

<edit> Whatever is said in above thread works well. But if you use "new" keyword to create Objects then Objects will be created irrespective of any range.
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 923
    
    1

Ilakya Mukunth wrote:
Danjel Nyberg wrote:Same goes for strings...

String a = "Test";
String b = "Test";
System.out.println(a==b); //prints true
String c = new String("Test");
System.out.println(a==c); //prints false

In this case since a and b are created via string litherals they point to the same object, but since c is created with new keyword this will be another object and therefore a is not the same as c

This is wierd in so many ways. In all normal cases you allways compare objects with equals method only...

/Danjel


I understand this example well. But according to my code snippet, all the Integer reference variables are assigned the literal values.




you are right that they are assigned literal values, but the literal values are AUTOBOXED . so what you get is wrapper objects.

also i would like to add when you compare wrapper object with literal using ==, the wrapper object is unboxed. so this results in primitive primitive equality checks. however in your case wrapper wrapper test is being done because of autoboxing.
Please post if you have doubts
Regards


OCPJP 6(100 %) OCEWCD 6(91 %) OCPJBCD(93%)
Ilakya Mukunth
Ranch Hand

Joined: Mar 13, 2012
Posts: 56
gurpeet singh wrote:
Ilakya Mukunth wrote:
Danjel Nyberg wrote:Same goes for strings...

String a = "Test";
String b = "Test";
System.out.println(a==b); //prints true
String c = new String("Test");
System.out.println(a==c); //prints false

In this case since a and b are created via string litherals they point to the same object, but since c is created with new keyword this will be another object and therefore a is not the same as c

This is wierd in so many ways. In all normal cases you allways compare objects with equals method only...

/Danjel


I understand this example well. But according to my code snippet, all the Integer reference variables are assigned the literal values.




you are right that they are assigned literal values, but the literal values are AUTOBOXED . so what you get is wrapper objects.

also i would like to add when you compare wrapper object with literal using ==, the wrapper object is unboxed. so this results in primitive primitive equality checks.
however in your case wrapper wrapper test is being done because of autoboxing.
Please post if you have doubts
Regards

I can understand the logic behind the program given by Danjel Nyberg. But please look at the code I have added. Assigning 10,100,1000 makes the output different for their respective run. Ex: if i1=i2=1000, it says they are not ==. but if i1=i2=100, both are ==.
Rameshwar Soni
Ranch Hand

Joined: Feb 03, 2011
Posts: 247
Did you went through the link which i gave you above gurpeet singh's answer ?
Ilakya Mukunth
Ranch Hand

Joined: Mar 13, 2012
Posts: 56
@Rameshwar Soni; Sorry. I did not read that. somehow missed it. Thanks for your kindness... It is of great help
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: == and != in Integer literals
 
Similar Threads
Boxing & unboxing
KB 235
classes Wrapper
difference between != or ==
Small doubt in Boxing & == & equals()