boxing,==, and equals()

I cannot understand that if

Integer i3 = 10;
Integer i4 = 10;
if(i3 == i4) System.out.println("same object");
if(i3.equals(i4)) System.out.println("meaningfully equal");

This example produces the output:
same object
meaningfully equal

reason for it given in k&B book is In order to save memory, two instances of the following wrapper objects will always be == when their primitive values are the same: Short and Integer from -128 to 127

But if i modify the code as follow

Integer i3 = 128;
Integer i4 = 128;
if(i3 == i4) System.out.println("same object");
if(i3.equals(i4)) System.out.println("meaningfully equal");

This example produces the output:
meaningfully equal

I cannot understand why it is behaving like this???
Plz explain me why the range for it is defined from -128 to 127 in case of short and integer as the integer can have 4 bytes in java.

The values -128 to 127 are already in a pool from the beginning. When you try it with 128 or any other value outside this range it has to create a new object.
[ February 28, 2006: Message edited by: Henrik Engert ]

Can you plz explain the pool here for my better understanding.

I would think the pool for Integers between -128 to 127 is similar to the pool that String has. The difference here is probably that the pool for Integers is created when you start the JVM....it's just a guess.

The String pool is filled when classes are loaded and when Strings are created with String s1 = "Hello"; ...it's also my guess.

Someone with better knowledge of the JVM should correct my guesses

The String pool is filled when classes are loaded and when Strings are created with String s1 = "Hello"; ...it's also my guess.

the first part of this statement is correct. i assume the second part should be replaced by "and when the intern() method is called on a String object"

because s1 = "Hello"; only gets a reference to the object in the String pool.

Thanks henrik you made me more curious to know about pools???

Plz somebody throw some light on pools and how it works in java.

Hi All,

Please correct me if I'm wrong.

I don't think that this kind of question where you have to determine whether or not a wrapper class was extracted from pool (using ==) will be charged in the exam.

I guess so just because it's unpredictable to know whether or not the class will be extracted from pool.

I've heard that sometimes it's plataform depend, so that's why it can be considered unpredictable.

Any comments are welcome.

I have heard this too, but it is always fun to know.

One question that came up on this forum was the String.replace and String.replaceAll. You have to look in the source code for the String class to figure out in which situation they reuse or creates a new String (It is not clear from the JavaDoc).

This is probably the reason these sort of questions have been left out on the test.

Plz somebody throw some light on pools and how it works in java.

What do you like to know? Do you like to know about the String pool? If so, the String pool is used to reuse already existing Strings (to save memory and speed up the application). As an example:

String s1 = "Hello"; // If !exist, it will be put into the pool of Strings.

String s2 = "Hello"; // This String already exist in the pool. Therefore it will reference the same existing String s1.

This makes s1 == s2 = true (But it is not recommended).

You should use s1.equals(s2) instead or s1.compareToIgnoreCase(s2) etc....

This is my knowledge about String pools. Correct me if I am wrong.

[ February 28, 2006: Message edited by: Henrik Engert ]
[ February 28, 2006: Message edited by: Henrik Engert ]

hi all,

Integer i3 = 10;
Integer i4 = 10;

if(i3 == i4) System.out.println("same object");
if(i3.equals(i4)) System.out.println("meaningfully equal");

Here i3==i4 will be true sometime and false sometime depending on JVM .
IN EXAM it is always false because it is not consistent through all JVM's

i3.equals(i4) is consistent in all jvm's .so always true in above example.

Agree with Srilatha that the result is depending on JVM. I have tested the code on my machine and the result for i3==i4 is false. Seems the data ranger doesn't matter that much.

By the way,
Integer i3 = 10;
Integer i4 = 10;

won't go through compiler, they should be declared as
Integer i3 = new Integer(10);
Integer i4 = new Integer(10);

Pls correct me if I am wrong.

Thanks,
Fen

Together, we will win!

u r right Huifen
Integer i3 = new Integer(10);
Integer i4 = new Integer(10);

i just copied code of gaurav singhal to explain him

Originally posted by Huifen Lu:
Agree with Srilatha that the result is depending on JVM. I have tested the code on my machine and the result for i3==i4 is false. Seems the data ranger doesn't matter that much.

By the way,
Integer i3 = 10;
Integer i4 = 10;

won't go through compiler, they should be declared as
Integer i3 = new Integer(10);
Integer i4 = new Integer(10);

Pls correct me if I am wrong.

Thanks,
Fen

In 1.5, autoboxing will automatically wrap the int in the Integer.

Thanks Keith! Yeah, I need to update my J2SE to 5, so that we can be in the same page.

Together, we will win!

Here i3==i4 will be true sometime and false sometime depending on JVM .IN EXAM it is always false because it is not consistent through all JVM's

But it is not true if you test in jdk 1.5 you will get the consistent behaviour that i3==i4 will be true in -128 to 127 range for integer.
That is the same thing told in K&B books.

Plz correct me if i am wrong

In jdk 1.5 is correct.

Should be

Integer i4 = 10 ;// gives you a compiler error

if you add the following bold line you get:

same object
meaningfully equal

Integer i4 = 10 ;// gives you a compiler error

If you use JDK 1.5 this will not give the compilation error because of it boxing capability.Boxing is a new feature that is added in JDK 1.5 onwards.

Integer i3 = new Integer(10); Integer i4 = new Integer(10); i3 = i4; if(i3 == i4) System.out.println("same object"); if(i3.equals(i4)) System.out.println("meaningfully equal");

As in this you are making both the refence to point the own object that why this is well understood.

But you have misunderstood the problem.
The following code well compile and run in JDK 1.5.

Integer i3 = 10;
Integer i4 = 10;
if(i3 == i4) System.out.println("same object");
if(i3.equals(i4)) System.out.println("meaningfully equal");

This example produces the output:
same object
meaningfully equal

And what happen is if you allocate the number within range -128 to 127 two different object reference point to same object in heap memory ie i3 an i4 are pointing to one object in heap memory. But if you change the value beyond this range they start pointing two different objects in heap memory.

Cannot understand why???

And what happen is if you allocate the number within range -128 to 127 two different object reference point to same object in heap memory ie i3 an i4 are pointing to one object in heap memory. But if you change the value beyond this range they start pointing two different objects in heap memory.

Cannot understand why???

It's easy. When you go beyond the -128 to 127 range Java creates a new Object instead of reusing the already existing one in the "Integer pool".

Never use "==" operator when you want to compare the int value wrapped by the object Integer. Use equals() instead.

-Henrik

does this mean that out of the -128 to 127 range auto-unboxing does not occur cos I think the two instances are compared to be thesame cos they are unboxed to be primitives then compared, or does it mean that they cant be unboxed to primitives out of that range

As far as I can understand it is not becoz of boxing and unboxing that happen in any range of values. But JVM will not allocate different object memory for the different object of same value in given range -128 to 127 but beyond this range it creates different objects in the memory. So two integer objects with value 10 will point to same object in memory but two integer object with value 128 will point to two different memory locations.