Community
Participate
Working Groups
Build Identifier: 20110916-0149 The following compiles in eclipse, but not in javac: Integer i = 'a'; Tested with javac 1.6.0_27 and 1.7.0 Reproducible: Always Steps to Reproduce: 1. Write the code in eclipse 2. Fail to complile it in javac
Also see this Stackoverflow thread for more details from people who know more about this than me: http://stackoverflow.com/q/7918134/623612
This is a bug. JLS chapter 5.2 http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.2 says: Assignment conversion occurs when the value of an expression is assigned (§15.26) to a variable: the type of the expression must be converted to the type of the variable. Assignment contexts allow the use of one of the following: an identity conversion (§5.1.1) 1.a widening primitive conversion (§5.1.2) 2.a widening reference conversion (§5.1.5) 3.a boxing conversion (§5.1.7) optionally followed by a widening reference conversion 4.an unboxing conversion (§5.1.8) optionally followed by a widening primitive conversion. In given example, 2 occurs followed by 3. This shouldnt be allowed. Note that this should be allowed: Integer i = (int)'a';
Will consider for this 3.8 M4.
(In reply to comment #2) > This is a bug. > > JLS chapter 5.2 > http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.2 > says: > > Assignment conversion occurs when the value of an expression is assigned > (§15.26) to a variable: the type of the expression must be converted to the > type of the variable. Assignment contexts allow the use of one of the > following: > an identity conversion (§5.1.1) > 1.a widening primitive conversion (§5.1.2) > 2.a widening reference conversion (§5.1.5) > 3.a boxing conversion (§5.1.7) optionally followed by a widening reference > conversion > 4.an unboxing conversion (§5.1.8) optionally followed by a widening primitive > conversion. > > In given example, 2 occurs followed by 3. This shouldnt be allowed. There is some confusion in the numbering/ordering. It appears we apply a widening primitive conversion, followed by a boxing conversion. Under investigation.
Here is an expanded test case: public class X { Integer f = 'a'; // Field declaration. public Integer main() { Integer i = 'a'; // local declaration with initialization. i = 'a'; // assignment Integer [] ia = new Integer [] { 'a' }; // array initializer. switch (i) { case 'a' : // case statement } return 'a'; // return statement. } } javac reports 6 errors, while eclipse compiles this code.
isConstantValueOfTypeAssignableToType call from org.eclipse.jdt.internal.compiler.ast.Statement.isBoxingCompatible(TypeBinding, TypeBinding, Expression, Scope) looks bogus - compare with every other call to isConstantValueOfTypeAssignableToType.
Actually problems stems from misapplication of the "narrowing primitive conversion followed by a boxing conversion" rules of 5.2 reproduced below: In addition, if the expression is a constant expression (˜15.28) of type byte, short, char or int : . A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable. . A narrowing primitive conversion followed by a boxing conversion may be used if the type of the variable is : Ÿ Byte and the value of the constant expression is representable in the type byte. Ÿ Short and the value of the constant expression is representable in the type short. Ÿ Character and the value of the constant expression is representable in the type char. Integer is not one of the target types for which this combo conversion is defined and permissible. Patch under test.
This is a long standing problem that dates back to the earliest days of autoboxing support. This commit 9c357e8e5c2796babe39d59e34a125e96b5dcee2 7 years ago introduced the problem.
Fix and tests released on 3.8 stream for M4 via commit 9d0a82ef5a22888c642513ca181ce9549bbdb17a. No plans to backport this as this is a long standing bug and not a regression.
Verified for 3.8M4 using build I20111202-0800
*** Bug 371834 has been marked as a duplicate of this bug. ***
