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

[Alex Buckley]

Hollis,

Thanks for trying the code on Oracle JDK 1.6. It was a little confusing 
earlier when you said "latest JDK accepts the following code", because 
the latest JDK (whether Oracle or Open) is 8 and it does not accept the 
code.

The problem is that JDK 7 (it'll be both Oracle and Open) accepts the 
code. Per JLS7, the code should not be accepted.

Vicente,

I think the changeset for 6979683 in JDK 7 made changes to the == 
operator which were undone by a changeset for JDK 8. It is right that 
the changes were undone, but I'd still like to know when and why. At 
minimum, there should be a javac bug with label release-note=YES so that 
the illegality of 3==x in 8 (v. in 7) is documented. Can you look into 
that please?

Alex

On 9/11/2013 1:42 PM, Hollis Waite wrote:
> 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?
>>>
>>
>