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

[Alex Buckley]

I don't understand the problem. JLS7 says 3==x is illegal; JLS8 is not 
changing in this area; JDK8 rejects the code.

The past is always of tremendous importance in language/compiler work. I 
reported JDK-6526449 shortly after JDK6 was released because javac's 
behavior for x==3 was different than 3==x, which is Really Bad. 
Unfortunately:

1. My report was confusing - casting conversion is a red herring because 
JLS 15.21.3 has never allowed a mix of int and Object types, even if int 
subsequently became castable to Object (and Object to int).

2. The evaluation was confusing - does "Fixed by 6979683" mean "x==3 and 
3==x are now both rejected" or "x==3 and 3==x are now both accepted" ? I 
suspect the former, which is why I'm concerned that you say you have a 
JDK which accepts 3==x. Please say more about the JDK version.

Alex

On 9/11/2013 11:54 AM, Hollis Waite wrote:
> 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?
>>
>