Home/ Questions/Q 8856291
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T14:19:25+00:00

Sorry to keep asking the basics but I don’t understand this simple code and

  • 0

Sorry to keep asking the basics but I don’t understand this simple code and why the first print statement goes through the compiler ok and even prints true, but the second print statement doesn’t compile, giving me an “incomparable types” error:

int in1 = 38;
Number Nn1 = in1;
System.out.println(in1 == Nn1);
System.out.println(Nn1 == in1);

I am not expecting this result, I thought it was pretty standard that == was symmetric?

I am using javac 1.6.0_26 and also NetBeans but get the same result, the first println statement compiles without problem and the second does not..

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I believe that, according to the Java Language Specification, neither way round should compile.

    It’s important firstly to understand that auto(un)boxing is only applied to expressions that meet certain criteria, and only for specific wrapper classes (Integer, Long etc, not Number).

    Now, in the case of ==, autounboxing is applied specifically when one is of
    [primitive] numeric type and the other is convertible to [primitive] numeric type     (JLS 15.12.1) according to the rules. And as we’ve just stated, “according to the rules”, Number is not convertible to a numeric primitive type.

    It is NOT, the case, for example, that the int should be converted to an Integer and then a reference comparison made: autoboxing is not specified to be applied to an == reference comparison (JLS 15.21.3).

    So if your compiler is allowing the cited code to compile, it does not obey the Java Language Specification.

    This behaviour makes sense because to perform a numeric comparison, the compiler needs to know the actual specific type of both operands in order to perform numeric promotion. You might think that you can compare, say, a Number with an integer, and that the compiler should just call .intValue() on the Number. But this is inappropriate, because if the original number type was actually a Float, then the correct comparison is actually to first convert the integer to a Float rather than the other way round. In other words, with a Number, the compiler doesn’t have all the information to correctly perform a numeric comparison with a primitive.

    • 0