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

Thu Sep 12 01:53:03 PDT 2013

On 11/09/13 22:10, Alex Buckley wrote:
> 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?

Hi Alex,

Yes as you mentioned the patch for bug: 
http://bugs.sun.com/view_bug.do?bug_id=8013357 made changes to the == 
operator. In our bug system the corresponding bug entry has the 
release-note=YES label. The changeset is in the master repo since last July.

Vicente

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