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

[Hollis Waite]

Oracle JDK 1.7.0_25 accepts both "3==x" & "x==3". Oracle JDK 1.6.0_45 rejects both. Eclipse rejects the code for all versions. I'm not sure what OpenJDK does. As indicated in my previous e-mail, I was talking this over with an Eclipse engineer and he agrees that it should be consistently rejected for all versions of spec. It sounds like you're in agreement. Based upon http://bugs.sun.com/view_bug.do?bug_id=6526449, it seems that Oracle may feel differently. I reached out to this mailing list to try and get everyone on the same page. Below matrix indicates my findings so far:

         6  7  8
Eclipse  N  N  ?

OpenJDK  ?  ?  ?
Oracle   N  Y  ?


----- 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 2:39 PM
Subject: Re: hg: jdk7/tl/langtools: 6979683: inconsistent interaction of	reference cast with box/unbox conversions leaves out a useful case

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