Wrapper ==

[Ganesh Pujar]

Hi all

 
Integer i1 = 1000;
Integer i2 = 1000;
if(i1 != i2) System.out.println("different objects");
if(i1.equals(i2)) System.out.println("meaningfully equal");
Produces the output:
different objects
meaningfully equal
 
BUT!!!!!!!!!!!
 
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
   

Lot of confusion???
How is it OK?
Please explane....

Tq!
GMP

[Vijay Gade]

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 objectmeaningfully equal

I don't know which compiler you are using, but in my compiler, it shows that i3 != i4, though they are meaningfully equal.

Thanks,
-Vijay

[Ganesh Pujar]

I have just pasted the code from K&B Chap 3, P 235 and 236

I also wonder how its possible as given in the book!

[Brad Clarke]

Originally posted by Ganesh MP:
I have just pasted the code from K&B Chap 3, P 235 and 236

I also wonder how its possible as given in the book!

The answer is in the middle of page 236:

"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.

This is why i1 and i2 are not equal (they have a value of 1000) but i3 and i4 are (they have a value of 10 so are considered to be equal objects).

I made a small change to the code from the book and added another line:

if(i1 == i2) System.out.println("same object");

If you add that extra line of code and change the values of i1 and i2 to 127, you get:
same object
meaningfully equal
same object
meaningfully equal

[Ganesh Pujar]

thats what i'm not able to digest!

[Shaliey Gowtham]

When "both variables are auto boxed" and the values in range
Long,Integer,Short,Byte = -128 -> 127
Character = '\u0000' -> '\u007f'
Boolean = true,false
are pooled and are assigned the same reference when the values are equal.
Its not pooled for Float and Double.

But if one is Wrapper Object and other the primitive,then always the value is compared in ==

If both Wrapper objects are created using the new() then == returns false.

<code>
import static java.lang.System.out;
class WrapperPool{

public static void main(String... vargs){

Integer i = 10, j = 10;
out.println(i==j); //true

i = j = 128;
out.println(i==j); //true

i = new Integer(128);
out.println(i==j); //false

i = new Integer(10);
j = new Integer(10);
out.println(i==j); //false

}
}
</code>
[ March 28, 2006: Message edited by: Shaliey G ]

[Ganesh Pujar]

Thanks Shialey!

But when i compile it under 1.5 it gives me the output as
true
true
false
false

Can you please explane?

[gaurav singhal]

Ganesh you are getting the right result refer this thread for more clarification.

https://coderanch.com/t/253063/java-programmer-SCJP/certification/boxing-equals

If that does not clarify your doubt let me know.

[Brad Clarke]

Here's my attempt at explaining Shaliey's example and the results that you and I got with JDK 1.5.

Integer i = 10, j = 10;
out.println(i==j); //true

This is correct. These are two separate objects created by declaring their type and using assignment operators to give them their initial values. Since their values are less than 127, they are considered to be equal (Page 236).

i = j = 128;
out.println(i==j); //false

I think this one is also labelled incorrectly. It should be true (and the compiled code says it's true). Assignment operations are processed in a right-to-left manner. So what is really happening is that j is being assigned a value of 128. Object j is then being assigned to object i. The object comparison evaluates to true.

i = new Integer(128);
out.println(i==j); //true as it is unboxed and compared

I think this one is also labelled incorrectly. It should be false (and the compiled code says it's false). This is an object comparison, not a value comparison.
i is being given a new object reference with a value of 128, so object i and object j are not equal.

In order to get a "true", you would need to do a value comparison:

out.println(i.equals(j)); //true as it is unboxed and compared

i = new Integer(10);
j = new Integer(10);
out.println(i==j); //false

This is correct. Creating an object using "new" results in a different object reference than when creating an object by declaring it's type and using an assignment operator. I'm still a bit fuzzy on this one since the values are less than 127 and I would have thought that the rule on page 236 would apply here.

[gaurav singhal]

Hi Brad

You are right.

Creating an object using "new" results in a different object reference than when creating an object by declaring it's type and using an assignment operator. I'm still a bit fuzzy on this one since the values are less than 127 and I would have thought that the rule on page 236 would apply here.

But see it is similar to what happen in case of Strings if you use the new operator it will create the two object one in heap memory to which reference will point and another in pool if the value is not there and it is in range -128 to 127. But note the reference in this case always point to object in heap so two object created using new operator there referece will point to two different object in heap even if there value is same and in range.

[Ganesh Pujar]

Thanks gaurav that helped a lot

But can anyone give me a Thumb of Rule to decide on such cases, just by following them? Plz!

[Shaliey Gowtham]

Thanks for correcting me guys.
I have edited the post
[ March 28, 2006: Message edited by: Shaliey G ]

[Sri Jad]

Integer i1 = 1000;//getting compilation error can not convert from int to Integer
Integer i2 = 1000;//getting compilation error can not convert from int to Integer

Why???

[Sri Jad]

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

Works Well!!

[Djoga Djogov]

Following this discussion the answer of Q.2 in the Self Test in the same chapter 3 confused me. I thought that the CardBoard object (c1) gets garbage collected but its associated Short wrapper object stays alive because there still is another CardBoard object, which has an associated Short wrapper with the same primitive value (5). And if both instance variables refer to the same object from the pool, disappearing of one of the variables shouldn't make the object eligible for GC.
Please, if anyone did this question say what he/she thinks.

[Shaliey Gowtham]

Sri Jad, you might be using jdk 1.4
auto boxing is from jdk1.5 only

[gaurav singhal]

Hi DJoga,

Following this discussion the answer of Q.2 in the Self Test in the same chapter 3 confused me. I thought that the CardBoard object (c1) gets garbage collected but its associated Short wrapper object stays alive because there still is another CardBoard object, which has an associated Short wrapper with the same primitive value (5). And if both instance variables refer to the same object from the pool, disappearing of one of the variables shouldn't make the object eligible for GC.
Please, if anyone did this question say what he/she thinks

To check this I have modified the code as follow

class CardBoard {
Short story = 5;
CardBoard go(CardBoard cb) {
cb = null;
return cb;
}
public static void main(String[] args) {
CardBoard c1 = new CardBoard();
CardBoard c2 = new CardBoard();
CardBoard c3 = c1.go(c2);
if(c1.story==c2.story){System.out.println("Same reference");}
//c1 = null;
// do Stuff
} }

and the output is Same reference. It signify what you are saying is right according to me the ans should be B (1 object eligible for GC).

I request the other people to confirm this.

[gaurav singhal]

For all those people who does not have book here is the question and the ans explaination which I feel is not satisfactory.

2. Given:
class CardBoard {
Short story = 5;
CardBoard go(CardBoard cb) {
cb = null;
return cb;
}
public static void main(String[] args) {
CardBoard c1 = new CardBoard();
CardBoard c2 = new CardBoard();
CardBoard c3 = c1.go(c2);
c1 = null;
// do Stuff
} }

When // doStuff is reached, how many objects are eligible for GC?
A. 0
B. 1
C. 2
D. Compilation fails.
E. It is not possible to know.
F. An exception is thrown at runtime.

Answer:
� 3 C is correct. Only one CardBoard object (c1) is eligible, but it has an associated Short wrapper object that is also eligible.
�˚ A, B, D, E, and F are incorrect based on the above. (Objective 7.4)

Ans should be B.

Gaurav
[ March 29, 2006: Message edited by: gaurav singhal ]

[Shaliey Gowtham]

Answer C is correct

CardBoard has-a Short(aggregation), so whenever an object becomes eligible
for GC all its has-a relation objects also becomes eligible for the GC
unless these objects are referenced from other reference.

Here when c1 is eligible for GC then c1.story also becomes eligible for GC
[ March 29, 2006: Message edited by: Shaliey G ]

[gaurav singhal]

But shailley note one thing the other reference c2.story also referencing to the same object becoz of pooling. Thus this object is not eligible for garbage collection due to aggregation as this object is still refrenced from outside.

[ashish kediya]

Originally posted by Ganesh MP:

read it is fundda of byte poll

[Shaliey Gowtham]

yes, i really haven't thought of pools
thanks

[Ganesh Pujar]

Can anyone give me a link to read more about POOLS! plz

[Bert Bates]

Hi guys -

In an earlier thread we talked about the pooling aspect of this question, and we agreed that we would change the question in the book so that the associated object's value was so big that the object wouldn't be in the pool.

It's listed on the errata in this thread:

https://coderanch.com/t/253088/java-programmer-SCJP/certification/JavaRanch-Exclusive-temporary-errata

hth,

Bert