wrapper object comparison

[milan chovatia]

Integer i3=10;
Integer i4=10;
if(i3 == i4)
{
System.out.println("they are same);
}
else
{
System.out.println("not same");

output: they are same

this is code part from book scjp6 by k&b and in that it says "in order to save memory instances of wrapper objects are always == when their primitive values are same."
but when i am running code i am getting output "not same".....
please someone can explain it....

[Keith Lynn]

Are you sure you typed the code in exactly?

[B. Katz]

milan chovatia wrote:Integer i3=10;
Integer i4=10;
if(i3 == i4)
{
System.out.println("they are same);
}
else
{
System.out.println("not same");

output: they are same

this is code part from book scjp6 by k&b and in that it says "in order to save memory instances of wrapper objects are always == when their primitive values are same."
but when i am running code i am getting output "not same".....
please someone can explain it....

Something that catches my eye here:

"in order to save memory instances of wrapper objects are always == when their primitive values are same."

Correct me if I am wrong, but I'm under the impression that an Integer is not a primitive int. Am I correct?

[Steve Luke]

milan chovatia wrote:... from book scjp6 by k&b and in that it says "in order to save memory instances of wrapper objects are always == when their primitive values are same."

For the code you listed above, the output should be "the are the same" (I mean, if you had typed it correctly and it actually compiled - which it doesn't the way you typed it). But the statement coming from the above book is not correct - and I am suprised if that is what it actually says. Wrapper classes like the Integer have a cache of values, used to save memory, and whenever two Integers references whose objects are in this cache are compared, the comparison would be equal if their primitive value was equal. But, unlike what the "quote", this isn't always true. It is only true when:
1) The Integer is boxed from a primitive (like Integer i3 = 10) -or- created using the Integer.valueOf() method.
2) AND when the values being stored are within a range of values that are cached (I don't think the range is specified, but -128 to +127 is a range I often see).

So, if you have a large value in the Integer, then no matter how you created the Integer, comparing like values using == would not yield true. And, if Integers were created using the constructors, then comparing them with == would not yield true.

Bottom line, don't rely on ==.

[milan chovatia]

public class Wrap
{
public static void main(String args[])
{ int j=10;
Integer i3=new Integer(10);
Integer i4=new Integer(10);
if(i4 == i3)
{
System.out.println("they are equal");
}
if(i4!=i3)
{
System.out.println("not equal");
}
}
}

see this is what i have done......
i am getting output : not equal

shouldnt i get they are equal??....if not then how i get equal....and i am compiling it fine...

[Henry Wong]

milan chovatia wrote:
i am getting output : not equal

shouldnt i get they are equal??....if not then how i get equal....and i am compiling it fine...

In your second example, you are getting "not equal" because they are not equal. Your first and second example are NOT the same. In the first case, it is using autoboxing, which is using the integer cache -- so they are the same object. In the second case, you are creating two objects, which obviously are not the same instance.


Now... The next question is... do you really care if the two references are pointing to the same instance? Or are you more concerned that the two references are pointing to an instance with the same value?

Henry

[Steve Luke]

milan chovatia wrote:shouldnt i get they are equal??

Steve Luke wrote: It is only true when:
1) The Integer is boxed from a primitive (like Integer i3 = 10) -or- created using the Integer.valueOf() method.
...
if Integers were created using the constructors, then comparing them with == would not yield true.

[Maxim Karvonen]

Steve Luke wrote:I don't think the range is specified, but -128 to +127 is a range I often see.

The minimal range is specified in JSL, 5.1.7. And this range is -128 to +127 for signed integrals and 0 to +127 for char. It is allowed to be greater in other JVMs but not smaller. Anyway, I never have used this knowledge and don't think it will be useful in future.

[Ivan Jozsef Balazs]

I ask myself sometimes whether autoboxing solves more problems than it creates.

[Stuart A. Burkett]

Ivan Jozsef Balazs wrote:I ask myself sometimes whether autoboxing solves more problems than it creates.

Isn't that a good thing ?

[milan chovatia]

Guys i am not getting they are equal in any condition....
Integer i=10;
Integer j=10;
m nt get i=j

show me the code of 2-3 line in which they ate equal...this code lines are not working at all
any help would be appreciated because i am getting too confuse...

[Steve Luke]

milan chovatia wrote:Integer i=10;
Integer j=10;
m nt get i=j

What does m nt get i=j mean? That aint Java

package example;

public class Wrappers
{
    public static void main(String[] args)
	{
	    Integer i = 10;
		Integer j = 10;
		if (i == j)
		{
		    System.out.println("Equal");
	    }
		else
		{
		    System.out.println("Not");
		}
	}
}

[Stuart A. Burkett]

milan chovatia wrote:Guys i am not getting they are equal in any condition....
Integer i=10;
Integer j=10;

What code are you actually using ? In two of your posts you have used this type of initialisation, but in your other post you have used

Integer i3=new Integer(10); 
Integer i4=new Integer(10); 

In the first case they will be equal, in the second case they won't for reasons that have already been explained.

[milan chovatia]

I am writing exacly same file as luke wrote.....one with package example
i am getting output "not equal"....dont know what's going on i checked it 100 times....
have you guys run this code/???

[Steve Luke]

milan chovatia wrote:I am writing exacly same file as luke wrote.....one with package example
i am getting output "not equal"

The code I posted will never print "not equal". It will either print "Equal" or "Not".

milan chovatia wrote:have you guys run this code/???

Yes. Before I posted it. What version of Java do you have? I actually don't think there is a version that does autoboxing and doesn't have the cache, but maybe I am wrong...

[James Boswell]

Example 1

Integer i1=new Integer(10); 
Integer i2=new Integer(10); 

Example 2

Integer i1=10; 
Integer i2=10; 

In example 1, i1 and i2 are different objects so == will return false.

In example 2, i1 and i2 are the same object so == will return true.

[Ivan Jozsef Balazs]

Stuart A. Burkett wrote:

Ivan Jozsef Balazs wrote:I ask myself sometimes whether autoboxing solves more problems than it creates.

Isn't that a good thing ?

If it solves more problems than it creates, it can be a good thing, but I am not sure.