Boxing and unboxing in Java 5

[Prahalad Deshpande]

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(b1==b2);
System.out.println(b1==b3);
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]

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.

Henry

[Gian Franco]

Hi,

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:
Boolean
Byte
...
...

Kind regards,

Gian

[Jim Yingst]

Although that's true Gian, in this case the rule Henry cited takes effect first. Consider this code for comparison:

        int x = 128;
        Integer y = x;
        Integer z = x;
        System.out.println(x == y);
        System.out.println(y == z);;

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.

[marc weber]

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

[Prahalad Deshpande]

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");
else
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...