United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8013357 : Javac accepts erroneous binary comparison operations

Details
Type:
Bug
Submit Date:
2013-04-26
Status:
Closed
Updated Date:
2014-06-05
Project Name:
JDK
Resolved Date:
2013-06-27
Component:
tools
OS:
Sub-Component:
javac
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
7u40,8
Fixed Versions:

Related Reports
Relates:
Relates:

Sub Tasks

Description
This code should not compile:

class Main {
public boolean func(Object obj) {
return obj == 0;
}
}

But javac (since JDK 7 accepts it).

The following variant:

class Main {
public boolean func(Object obj) {
return 0 == obj;
}
}

should also not compile - but note that this was accepted since JDK 5.

Relevant JLS section is 15.21. Javac seems to treat this as a reference comparison, but a reference comparison is only allowed when BOTH operands are reference types.
                                    

Comments
URL:   http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/5c548a8542b8
User:  lana
Date:  2013-07-05 18:17:02 +0000

                                     
2013-07-05
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c548a8542b8
User:  emc
Date:  2013-06-27 21:46:56 +0000

                                     
2013-06-27
Change ready for push, awaiting final review.
                                     
2013-06-19
CCC approved.  This change will be tagged for a release note.
                                     
2013-05-29
Suggested release note text:

The type rules for binary comparisons in JLS Section 15.21 will now be correctly enforced by javac.  Since JDK5, javac has accepted some programs with Object-primitive comparisons that are incorrectly typed according to JLS 15.21.  These comparisons will now be correctly identified as type errors.
                                     
2013-05-29
Awaiting CCC approval
                                     
2013-05-08
Suspect some relation to the changes made under JDK-6979683.
                                     
2013-05-03
A JPRT run reveals that there are int != Object comparisons in one of the test suites (DivModTest).  This is almost certainly a mistake; however, it does raise an interesting point: how much code out there will be "broken" by this change?
                                     
2013-05-03
This is caused by boxing.  Javac interprets 0 == obj as equivalent to Integer.valueOf(0) == obj.  More specifically, this is *not* a null pointer check, as the equivalent syntax in C++ would be.

Also, current javac accepts both 0 == obj and obj == 0.  It also accepts 0.0 == obj, 1 == obj, and true == obj.  More generally, a primitive type can be used anywhere that a supertype of its box is expected.


I would like some clarification here.  Is the scope of this bug limited solely to comparisons?  If so, then this suggest special rules governing boxing/unboxing for comparisons; this needs to be thought through carefully.  For example, consider 1 + 2 == obj, 0.add(1) == obj, etc.
                                     
2013-04-30



Hardware and Software, Engineered to Work Together