my dog learned polymorphism
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Boxing and unboxing in Java 5 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 "Boxing and unboxing in Java 5" Watch "Boxing and unboxing in Java 5" New topic

Boxing and unboxing in Java 5

Prahalad Deshpande

Joined: Oct 31, 2006
Posts: 14
Well here is some code that I have again from a mock exam site
public class Boxing6 {
public static void main(String[] args) {
Boolean b1 = new Boolean(true);
Boolean b2 = new Boolean(true);
boolean b3 = true;
Boolean b4 = true;
System.out.println(b3 == b4);
System.out.println(b1 == b4);
What is the output for the above program?
1)false true true false
2)false false false false
3)true true true true
4)false false true true

My answer for this question was 2) but I WAS Wrong!! Well the answer turns out tobe 1)
I tried the code out on my compiler and indeed the answer was one!
Can someone explain to me how the == operator treats b1( a Boolean object) and b3 (a boolean primitive) as equal?

Thanks in advance for the help
Henry Wong

Joined: Sep 28, 2004
Posts: 20526

According to the specification, when comparing a boxed reference with a primative value, the compiler will choose to unbox the reference and compare the values.


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Gian Franco
Ranch Hand

Joined: Dec 16, 2003
Posts: 977

I think you need the following explanation from K&B:
In order to save memory, two instances of the following wrapper objects will always be == when their primitive values are the same:

Kind regards,


"Eppur si muove!"
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Although that's true Gian, in this case the rule Henry cited takes effect first. Consider this code for comparison:

Here an Integer with a value outside the range [-128,127] is not guaranteed to be always autobox to the same instance. and in practice, all current JVM's I'm familiar with will print false for the last statement. But true would also be perfectly legal, if anyone chooses to implement a JVM that way. Anyway though - why does "x == y" still evaluate to true? It's because as Henry said, when comparing a boxed reference to a primitive value, the boxed reference is unboxed. So for evaluating x == y it doesn't matter whether the boxed instances are pooled or not - it just matters that the unboxed primitives are equal.

"I'm not back." - Bill Harding, Twister
marc weber

Joined: Aug 31, 2004
Posts: 11343

For reference, see JLS - 15.21.2 Boolean Equality Operators == and !=.

"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
Prahalad Deshpande

Joined: Oct 31, 2006
Posts: 14
Thank you all especially Henry and Marc for your guidance. It now makes abolute sense. Just correct me if what I have got is wrong:

The JLS states that in case of the Boolean equality operators the values are first unboxed and then their values are compared. Hence Boolean true == boolean true yields true.
In the same way when we have an Integer object and an int what happens is since int comes in the list of prmitives for which the values are compared only after unboxing; an Integer object with value 10 is the same as an int with an object 10

The above conclusion for Integer objects is based ont the following piece of code that I wrote to test it out
public class testintobjects
public static void main(String[] args)
Integer intObject=10;
int intPrimitive=10;
if(intObject == intPrimitive)
System.out.println("The Integer object is equal to the int primitive");
System.out.println("The Integer object is not equal to the int primitive");

It gives me the follwoing output
The Integer object is equal to the int primitive
Press any key to continue...
I agree. Here's the link:
subject: Boxing and unboxing in Java 5
It's not a secret anymore!