When the JVM create a new Wrapper and when the JVM use a living one? ( K&B 5.0)

[Eric Janssens]

passage of p 236, K&B 5.0:

"... In order to save memory, two instances of the following wrapper objects will always be == when their primitive values are the same:

* Boolean
* Byte
* Character from \u0000 to \u007f ( 7f is 127 in decimal )
* Short and Integer from -128 to 127 "

But

public class WrapperTest{
public static void main(String[] args){
Integer int1= 23;
Integer int2= 23;
Integer int3= new Integer(23);
Integer int4= new Integer("23");
Integer int5= Integer.valueOf(23);
Integer int6= Integer.valueOf("23");
Integer int7= Integer.valueOf("10111", 2);// 23
System.out.println(int1 == int2 );// true
System.out.println(int1 == int3 );// false
System.out.println(int1 == int4 );// false
System.out.println(int1 == int5 );// true
System.out.println(int1 == int6 );// false
System.out.println(int1 == int7 );// false
 
Integer int01= 14;
Integer int02= 15;
int02--;
System.out.println(int01 == int02 );// true
}
}

So, when exactly the JVM decide to pick a Wrapper in its heap and when the JVM decide it is the time to create a new Wrapper object ( from the spec and not from a given JVM implementation ) ?

note: I have replace pool by heap since i am not even sure that there is a pool for wrapper ( but it seems so )
[ February 14, 2006: Message edited by: John Smith ]

[Joshua Smith]

John-

The call to new Integer() will force it to create a new object and not to use the memory saving option. This is the case with the String pool as well.

String string1 = "abc";
String string2 = "abc";
String string3 = new("abc");

string1 == string2 // true
string1 == string3 // false
string2 == string3 // false

I'm not sure about the valueOf() ways of creating wrappers. Maybe someone else can provide some insight on that.

Josh

[Eric Janssens]

I must also say that in the K&B book, they show a correct example with 2 wrapper objects contruct via the same primitive literal where both are == But the statement from K&B in my previous post seems to be more general than just the literal assignation case.

ex of K&B:

Integer i3= 10;
Integer i4= 10;
if( i3 == i4 ) System.out.println("same object");
if( i3.equals(i4) ) System.out.println("meaningfully equal");
[ February 14, 2006: Message edited by: John Smith ]

[Purushoth Thambu]

JVM will share the reference of constants defined in the compile time. In the snippet address of constant "23" is referenced by int1, int2 and int5. Since valueOf function is given same integer constant 23 the compile optimizes to use the same references.

[Eric Janssens]

If it happens only at Compile time, why this:

Integer int01= 14;
Integer int02= 15;
int02--;
System.out.println(int01 == int02 );// true

or this:

Integer int03= 18;
Integer int04= 19;
Integer int05= int03;
Integer int06= Integer.valueOf(18);
Integer int07= Integer.valueOf(int03);
Integer int08= Integer.valueOf(--int04);
System.out.println(int03 == int05);// true
System.out.println(int03 == int06);// true
System.out.println(int03 == int07);// true
System.out.println(int03 == int08);// true

It seems that the JVM decide at least sometimes at runtime when to pick Wrapper in its pool.
[ February 14, 2006: Message edited by: John Smith ]

[Purushoth Thambu]

My first answer is based on JKD 1.4 but after trying the example posted I see there are lot more changes in JDK 1.5.

About this snippet

Integer int01= 14;
Integer int02= 15;
int02--;
System.out.println(int01 == int02 );// true

There is just one answer I could think of.

The experssion
Integer int01 = 14 will result in "Boxing Conversion" and the reference object must have an flag to indicate it's boxed object.

When operators like +,- are applied on the Boxed object it's first unboxed, then arithmetic operator must be applied and finally boxed backed to the reference type.

That's what must be happening for == operator as well.
It's not comparing the reference but the unboxed value of the reference object.

If there is another answer to this snippet I would like to know it.

[Eric Janssens]

Originally posted by Purushothaman Thambu:

That's what must be happening for == operator as well.
It's not comparing the reference but the unboxed value of the reference object.

It cant be, or == on wrappers of same value would always return true which is not the case (obviously).

But it s true for primitive == wrapper comparaison (from what i had read from a previous post)
[ February 14, 2006: Message edited by: John Smith ]

[Purushoth Thambu]

Objects/Wrappers created with new keyword will not be unboxed and that must be the reason why == will fail of object wrappers created with new keyword.