aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes When the JVM create a new Wrapper and when the JVM use a living one? ( K&B 5.0) 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 "When the JVM create a new Wrapper and when the JVM use a living one? ( K&B 5.0)" Watch "When the JVM create a new Wrapper and when the JVM use a living one? ( K&B 5.0)" New topic
Author

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

Eric Janssens
Ranch Hand

Joined: Sep 26, 2005
Posts: 53
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



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
Ranch Hand

Joined: Aug 22, 2005
Posts: 193
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


Rational Pi Blog - Java, SCJP, Dev Bits- http://rationalpi.wordpress.com
Eric Janssens
Ranch Hand

Joined: Sep 26, 2005
Posts: 53
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
Ranch Hand

Joined: May 24, 2003
Posts: 425
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
Ranch Hand

Joined: Sep 26, 2005
Posts: 53
If it happens only at Compile time, why this:

or this:

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
Ranch Hand

Joined: May 24, 2003
Posts: 425
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



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
Ranch Hand

Joined: Sep 26, 2005
Posts: 53
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
Ranch Hand

Joined: May 24, 2003
Posts: 425
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: When the JVM create a new Wrapper and when the JVM use a living one? ( K&B 5.0)