wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes confusion in == 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 "confusion in == " Watch "confusion in == " New topic
Author

confusion in ==

narendra bhattacharya
Ranch Hand

Joined: Feb 17, 2010
Posts: 66




This produces compiler error ..

but this does not.....



This compiles and produces true as output..


HOWWWWWWWWWWWW


SCJP1.6,SCWCD1.5
Ganesh Dhakshinamurthy
Greenhorn

Joined: Apr 08, 2007
Posts: 11
It doesn't work both ways. Please check your code again.
Afzal Rehman
Ranch Hand

Joined: Dec 16, 2009
Posts: 39
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 ...........


SCJP 6.0
narendra bhattacharya
Ranch Hand

Joined: Feb 17, 2010
Posts: 66
but it works i have checked
narendra bhattacharya
Ranch Hand

Joined: Feb 17, 2010
Posts: 66
narendra wrote:It does.
Ganesh Dhakshinamurthy
Greenhorn

Joined: Apr 08, 2007
Posts: 11
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
Ranch Hand

Joined: Feb 17, 2010
Posts: 66
narendra wrote:sir i have written both the codes one compliles and one give compilation error..
narendra bhattacharya
Ranch Hand

Joined: Feb 17, 2010
Posts: 66
sir
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18117
    
  39


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

Henry


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

Joined: Feb 17, 2010
Posts: 66
2 nd code is running and giving output "true".....
Rian Nolan
Greenhorn

Joined: Jun 21, 2006
Posts: 9
Weird. The tests:
all return true, but
throws "incomparable types" at compile time
narendra bhattacharya
Ranch Hand

Joined: Feb 17, 2010
Posts: 66
sir java 1.6 sun microsystem..
Ganesh Dhakshinamurthy
Greenhorn

Joined: Apr 08, 2007
Posts: 11
Neither version works for me too. In checked it in 5.0 and 6.0
narendra bhattacharya
Ranch Hand

Joined: Feb 17, 2010
Posts: 66
but why such output ..
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18117
    
  39

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

Joined: Feb 17, 2010
Posts: 66
sir there are many question like this.... how will i find way to solve it..
Afzal Rehman
Ranch Hand

Joined: Dec 16, 2009
Posts: 39
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
Ranch Hand

Joined: Jun 28, 2009
Posts: 172
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
Ranch Hand

Joined: Dec 16, 2009
Posts: 39
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
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
I have JDK 1.6 but none of the cases are working for me. Strange.

Best Regards


Prithvi,
My Blog, Follow me on Twitter,Scjp Tips, When you score low in mocks, Generics,Scjp Notes, JavaStudyGroup
bhanu chowdary
Ranch Hand

Joined: Mar 09, 2010
Posts: 256
I tried with 1.5 and neither of them is working.
Harpreet Singh janda
Ranch Hand

Joined: Jan 14, 2010
Posts: 317

Me to tried with JDK 1.5 , but not working
John McParland
Ranch Hand

Joined: May 11, 2009
Posts: 92

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.


Passed: SCJP 6 (90%), SCJD 6
Other: Spring training, extensive Swing experience
Anupam Jain
Ranch Hand

Joined: Mar 16, 2010
Posts: 61

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

However, in the second case


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


SCJP-6.0 OCPJWCD-5.0
Anupam Jain
Ranch Hand

Joined: Mar 16, 2010
Posts: 61

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

Joined: Feb 17, 2010
Posts: 66
i think you are doing big mistakes.....
John McParland
Ranch Hand

Joined: May 11, 2009
Posts: 92

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

Joined: Feb 17, 2010
Posts: 66
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..
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: confusion in ==
 
Similar Threads
Doubt
boxing method call doubt
Qa dd'rouy Again
Pattern matching doubt
David Smalley