confusion in ==

[narendra bhattacharya]

class P
{
public static void main(String [] args)
{
int n=4;
Number p=4;
System.out.println(p==n);


}


}

This produces compiler error ..

but this does not.....

   
class P
{
public static void main(String [] args)
{
int n=4;
Number p=4;
System.out.println(n==p);

}


}
 

This compiles and produces true as output..


HOWWWWWWWWWWWW

[Ganesh Dhakshinamurthy]

It doesn't work both ways. Please check your code again.

[Afzal Rehman]

Interesting but i think Number is a class which can have Integer and can return int when it's do == and it's use AutoBoxing.

but i need to clear myself it is just work on left hand side ...........

[narendra bhattacharya]

but it works i have checked

[narendra bhattacharya]

narendra wrote:It does.

[Ganesh Dhakshinamurthy]

It is giving me compiler error "Incompatible operand types" when i just use the code you have pasted here.
Are you sure you used "int" primitive not Integer?

[narendra bhattacharya]

narendra wrote:sir i have written both the codes one compliles and one give compilation error..

[narendra bhattacharya]

sir

[Henry Wong]

What vendor and version of java are you using? Neither case works for me.

Henry

[narendra bhattacharya]

2 nd code is running and giving output "true".....

[Rian Nolan]

Weird. The tests:

(int == Number)
(int == Integer)
(Integer == int)

all return true, but

(Number == int)

throws "incomparable types" at compile time

[narendra bhattacharya]

sir java 1.6 sun microsystem..

[Ganesh Dhakshinamurthy]

Neither version works for me too. In checked it in 5.0 and 6.0

[narendra bhattacharya]

but why such output ..

[Henry Wong]

narendra bhattacharya wrote:sir java 1.6 sun microsystem..

Just tried the Sun 1.6 JDK, and sure enough, one case works while the other case doesn't. Don't know why though.

Henry

[narendra bhattacharya]

sir there are many question like this.... how will i find way to solve it..

[Afzal Rehman]

sure one case will work ... but another one doesn't which i have mention earlier. One case make sense but what about if
Number is on right hand side...

[Jacob Sonia]

The "==" as per me is always reflexive. It should also work both ways otherwise it is not a correct implementation. Should complain about this to Sun:)

[Afzal Rehman]

Hey I have doubt about left hand side why it's not work but still confuse i have seen in JLS but nothing clearly mention about this

if the operands of an equality operator are both of numeric type, or one is of numeric type and the other is convertible (§5.1.8) to numeric type, binary numeric promotion is performed on the operands (§5.6.2). If the promoted type of the operands is int or long, then an integer equality test is performed; if the promoted type is float or double, then a floating-point equality test is performed.

Note that binary numeric promotion performs value set conversion (§5.1.13) and unboxing conversion (§5.1.8). Comparison is carried out accurately on floating-point values, no matter what value sets their representing values were drawn from.

[Prithvi Sehgal]

I have JDK 1.6 but none of the cases are working for me. Strange.

Best Regards

[bhanu chowdary]

I tried with 1.5 and neither of them is working.

[Harpreet Singh janda]

Me to tried with JDK 1.5 , but not working

[John McParland]

Hi,

I tried this;

class Test
{
public static void main(String [] args)
{
int n=4;
Number p=4;
System.out.println(p==n); // incomparable types: java.lang.Number and int
System.out.println(n==p); // box then widen
// Added these lines
Integer q = 4;
System.out.println(q == n); // box
System.out.println(n == q); // unbox
}
}

And looking at the boxing rules;

You CANNOT widen from one wrapper type to another (IS-A fails.)
You CANNOT widen then box. (An int can't become a Long.)
You can box and then widen. (An int can become an Integer then a Number.)

I would guess that in the first case, it is trying to unbox Number but there's no primitive type for it to be unboxed to. I don't know why it chooses the Number variable as opposed to the int one other than it is the first thing in the comparisson.

[Anupam Jain]

There is this note I found in the SCJP book from Kathey Sierra...

"When == is used to compare a primitive to a wrapper, the wrapper will be unwrapped and the comparison will be primitive to primitive"

This implies to the first case where...

    
int p=4;
Number q=4;
System.out.println(p==q);             //produces 'true'

However, in the second case

    
int p=4;
Number q=4;
System.out.println(q==p);             //compile time error

What I think is... since the first operand to == operator is a reference type... compiler expects to have a reference type as the second argument too, which is not there... so... arrrgghh its really confusing...

[Anupam Jain]

John McParland wrote:


And looking at the boxing rules;

You CANNOT widen from one wrapper type to another (IS-A fails.)
You CANNOT widen then box. (An int can't become a Long.)
You can box and then widen. (An int can become an Integer then a Number.)

The first and the third rule listed here contradict each other.. isn't??

I should've merged it with the above post only.. made a mistake... sorry.. I don't know how to do it now...

[narendra bhattacharya]

i think you are doing big mistakes.....

[John McParland]

The first and the third rule listed here contradict each other.. isn't??

I think they are correct. Take and Integer and a Long. They are both subclasses of Number so you can widen references of either to Number. However you cannot have an int, box to Integer then widen to Long because Integer is not a subclass of Long.

[narendra bhattacharya]

ok its fine concept but it should work in both cases why in one case it is working and other case it is showing compiler error....

== have left to right associativity..