EVALUATION
As specified by JLS3 15.21.1 Numerical Equality Operators == and !=:
"If the operands of an equality operator are both of numeric type, or
one is of numeric type and the other is convertible (??5.1.8) to numeric
type, binary numeric promotion is performed on the operands (??5.6.2).
If the promoted type of the operands is int or long, then an integer
equality test is performed; if the promoted type is float or double,
then a floating-point equality test is performed."
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.21.1
(convertible means unboxing conversion).
|
|
|
EVALUATION
Closer examination reveals that the compiler is right.
* if *both* types are numeric, or
* if one is numeric and the other is convertible to a numeric type
Not if *both* are convertible to a numeric type.
|
|
|
EVALUATION
I'll add the test case to compiler's regression tests to ensure
this misunderstanding does not arise again.
|
|
|
EVALUATION
So this is a reference equality as specified by JLS3, 15.21.3
Reference Equality Operators == and !=
"A compile-time error occurs if it is impossible to convert the
type of either operand to the type of the other by a casting
conversion (??5.5). The run-time values of the two operands would
necessarily be unequal."
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.21.3
|
|
|
SUGGESTED FIX
Webrev of changes: http://sa.sfbay/projects/langtools/bugid_summary.pl?bugid=5082929
See also attachment 5082929.tar.gz.
|
|
|
EVALUATION
I agree that the JLS interprets ==(Float,Integer) as a reference equality operator rather than a numerical equality operator. The compiler is correct in giving an error.
(This is a shame; I believe most programmers would want == to be a numerical equality test if given two types convertible to numeric types. But I'm not proposing to change the JLS.)
|
|
|
CONVERTED DATA
BugTraq+ Release Management Values
COMMIT TO FIX:
dragon
|
|
|
EVALUATION
Yes.
###@###.### 2004-08-04
|
|
|