hg: jdk7/tl/langtools: 6979683: inconsistent interaction of reference cast with box/unbox conversions leaves out a useful case

[Hollis Waite]

Wasn't my intention to dredge up the past. However, I was looking for some guidance with respect to an Eclipse bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=416950). It sounds like you're confirming that Oracle JRE 7 behavior (i.e. accepting primitive/Object comparisons) is invalid? I can't imagine that we're cool with inconsistent behavior between JDK implementations. *Someone* has to be wrong.


----- Original Message -----
From: Alex Buckley <alex.buckley at oracle.com>
To: "compiler-dev at openjdk.java.net" <compiler-dev at openjdk.java.net>
Cc: 
Sent: Wednesday, September 11, 2013 1:43 PM
Subject: Re: hg: jdk7/tl/langtools: 6979683: inconsistent interaction of	reference cast with box/unbox conversions leaves out a useful case

Please be more specific than "latest JDK". In the JDK 8 Developer 
Preview, the 3==x comparison is rejected with the message that int and 
Object are incomparable types. That is consistent with JLS7 15.21.

Now, this topic has some history. It used to be that javac was sensitive 
to the order of the operands; see JDK-6526449. I happen to agree with 
you that == should accept a mix of primitive and reference types, 
provided that casting conversion can convert one type to the other. 
However, it didn't happen in SE 7 (hence 3==x is rejected) and we're not 
revisiting it now.

Alex

On 9/11/2013 9:29 AM, Hollis Waite wrote:
> Since Java 7 allows implicit chained casts, should it be legal to compare primitives with Objects via the '==' operator? JLS 15.21 states:
>
>
>    The equality operators may be used to compare two operands that
>    are convertible (§5.1.8) to numeric type, or two operands of
>    type boolean or Boolean, or two operands that are each of either
>    reference type or the null type. All other cases result in a
>    compile-time error.
>
> However, latest JDK accepts the below code:
>
>    Object x = "";
>    boolean a = (3 == x);
>
> It seems to me that the new '=' guidelines are inconsistent with official (but not *actual*) behavior of '=='. Should JLS 15.21 be updated?
>