aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Wrapper == 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 "Wrapper ==" Watch "Wrapper ==" New topic
Author

Wrapper ==

Ganesh Pujar
Ranch Hand

Joined: Mar 22, 2006
Posts: 45
Hi all


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

Tq!
GMP
Vijay Gade
Ranch Hand

Joined: Jul 04, 2005
Posts: 81

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

Joined: Mar 22, 2006
Posts: 45
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
Greenhorn

Joined: Mar 27, 2006
Posts: 20
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 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
Ranch Hand

Joined: Mar 22, 2006
Posts: 45
thats what i'm not able to digest!
Shaliey Gowtham
Ranch Hand

Joined: Mar 20, 2006
Posts: 104
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
Ranch Hand

Joined: Mar 22, 2006
Posts: 45
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
Ranch Hand

Joined: Nov 18, 2005
Posts: 135
Ganesh you are getting the right result refer this thread for more clarification.

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

If that does not clarify your doubt let me know.
Brad Clarke
Greenhorn

Joined: Mar 27, 2006
Posts: 20
Here's my attempt at explaining Shaliey's example and the results that you and I got with JDK 1.5.


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 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 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:




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

Joined: Nov 18, 2005
Posts: 135
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
Ranch Hand

Joined: Mar 22, 2006
Posts: 45
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
Ranch Hand

Joined: Mar 20, 2006
Posts: 104
Thanks for correcting me guys.
I have edited the post
[ March 28, 2006: Message edited by: Shaliey G ]
Sri Jad
Ranch Hand

Joined: Apr 25, 2005
Posts: 49
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
Ranch Hand

Joined: Apr 25, 2005
Posts: 49
Integer i1 = new Integer(1000);
Integer i2 = new Integer(1000);

Works Well!!
Djoga Djogov
Greenhorn

Joined: Mar 28, 2006
Posts: 5
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
Ranch Hand

Joined: Mar 20, 2006
Posts: 104
Sri Jad, you might be using jdk 1.4
auto boxing is from jdk1.5 only
gaurav singhal
Ranch Hand

Joined: Nov 18, 2005
Posts: 135
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
Ranch Hand

Joined: Nov 18, 2005
Posts: 135
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
Ranch Hand

Joined: Mar 20, 2006
Posts: 104
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
Ranch Hand

Joined: Nov 18, 2005
Posts: 135
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
Greenhorn

Joined: Mar 02, 2006
Posts: 15
Originally posted by Ganesh MP:

read it is fundda of byte poll
Shaliey Gowtham
Ranch Hand

Joined: Mar 20, 2006
Posts: 104
yes, i really haven't thought of pools
thanks
Ganesh Pujar
Ranch Hand

Joined: Mar 22, 2006
Posts: 45
Can anyone give me a link to read more about POOLS! plz
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8829
    
    5
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:

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

hth,

Bert


Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Wrapper ==