javac bug: comparing a primitive == object

[Neal Gafter]

This is very confusing.  Are you telling me that a "closed" bug is used to
indicate a known problem that may be fixed in the future?  It isn't clear
to me how someone reading the bug description will understand that this
particular problem (current spec vs compiler disagreement described below)
exists.  6212662 appears to request a change in semantics for many cases,
while the one issue described below is simply a bug.

In this case, I do not believe that javac can be made conforming without
breaking a substantial body of code.  I believe the language specification
must be changed to bring them in alignment.  That would suggest that this
"closed but open" bug is misclassified as a javac issue (and that
compiler-dev might not be the right forum, though there is no other forum
for language specification issues).  I also do not believe that it should
wait to be fixed until someone takes on the project of overhauling the
entire area of comparisons versus boxing (i.e. never).

Is the language spec really on life support?

Cheers,
Neal

On Tue, Jan 22, 2013 at 12:32 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

> It's still there as http://bugs.sun.com/view_bug.**do?bug_id=6212662<http://bugs.sun.com/view_bug.do?bug_id=6212662>,
> marked as "Future Project".
>
> Since JLS7 15.21 is unchanged from JLS3 15.21, I agree that javac
> continues to be non-conforming.
>
> Please direct all further comments to compiler-dev at openjdk.java.net.
>
> Alex
>
>
> On 1/21/2013 6:26 PM, Neal Gafter wrote:
>
>> Alex-
>>
>> Is there a bug number for this issue, which we discussed a few years
>> ago?  Neither javac nor the specification appear to have been fixed.
>>
>> Cheers,
>> Neal
>>
>>
>> p.s. To refresh your memory, here's the reduced test case:
>>
>>     Object a = 3.5;
>>     System.out.println(3.5 == a);
>>
>>
>> And here is the JLS3 excerpt from 15.21 that requires it to be an error:
>>
>>     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.
>>
>>
>> In short, javac doesn't comply with its specification.
>>
>> On Thu, Apr 30, 2009 at 2:08 PM, Alex Buckley <Alex.Buckley at sun.com
>> <mailto:Alex.Buckley at sun.com>> wrote:
>>
>>     Having inspected the history more closely, it turns out that Joe
>>     wrote the first eval in 2004 re: new objects, and Peter closed it a
>>     few days later. I think I came across it in 2007 as a SeeAlso for
>>     another old bug I was looking at. Anyway, the path is clear now.
>>
>>     Alex
>>
>>     Neal Gafter wrote:
>>
>>         Thanks!
>>
>>
>>         On Thu, Apr 30, 2009 at 1:24 PM, Alex Buckley
>>         <Alex.Buckley at sun.com <mailto:Alex.Buckley at sun.com>
>>         <mailto:Alex.Buckley at sun.com <mailto:Alex.Buckley at sun.com>>**>
>> wrote:
>>
>>              True, the complaint about flyweights confused the issue,
>>         and neither
>>              Gilad nor I thought about == much. I'll fix up the eval and
>>         move it
>>              to compiler.
>>
>>              Alex
>>
>>
>>              Neal Gafter wrote:
>>
>>                  bug 6212662 was improperly closed as not a bug...
>>
>>                  the third edition of the JLS requires the error that
>>         the bug
>>                  report requests. Here's the reduced test case:
>>
>>                  Object a = 3.5;
>>                  System.out.println(3.5 == a);
>>
>>                  And here is the JLS3 excerpt that requires it to be an
>>         error:
>>
>>                  "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."
>>
>>                  In short, javac doesn't comply with its specification.
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130122/84e9b9d6/attachment.html