Note that binary numeric promotion performs value set conversion (§5.1.13) and may perform unboxing conversion (§5.1.8).
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Rob Spoor wrote:You missed one small little line in section 15.21.1:
Note that binary numeric promotion performs value set conversion (§5.1.13) and may perform unboxing conversion (§5.1.8).
Steve
Campbell Ritchie wrote:Shame you missed the line about unboxing.
Campbell Ritchie wrote:That case is indeed covered by the JLS link I quoted. It says if one is numeric and the other convertible to numeric…, with a link to §5.18 which says that an Integer is convertible to an int by unboxing, so that covers <int, Integer> and <Integer, int>.
When I talked about the {numeric, ref} case, the 'ref' in there is not convertible to a numeric primitive (i.e., cannot be unboxed).
Wout Er wrote:If so, as Steve mentioned, I don't consider unboxing as auto-boxing.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Steve
Wout Er wrote:Indeed interesting. Yet, since it's not specified in the JLS, this seems to be platform-specific and therefore I only trust the 'No' answer to the question posed in the subject.
It is a compile-time error 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.
Tony Docherty wrote:
Comparing an int to an Object means it no longer comes under the section "15.21.1. Numerical Equality Operators == and !=" but rather it comes under the section "15.21.3. Reference Equality Operators == and !=" where it says
It is a compile-time error 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.
The casting conversion specified in 5.5 allows for an auto-boxing conversion and so the int is converted to an Integer and the two object's are compared to see if they are the same object.
If the operands of an equality operator are both of either reference type or the null type, then the operation is object equality.
And, would you believe, the Java7 edition says:-15.21.3 Reference Equality Operators == and !=
If the operands of an equality operator are both of either reference type or the null type, then the operation is object equality.
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.
At run time, the result of == is true if the operand values are both null or both refer to the same object or array; otherwise, the result is false.
The result of != is false if the operand values are both null or both refer to the same object or array; otherwise, the result is true.
While == may be used to compare references of type String, such an equality test determines whether or not the two operands refer to the same String object. The result is false if the operands are distinct String objects, even if they contain the same sequence of characters. The contents of two strings s and t can be tested for equality by the method invocation s.equals(t). See also §3.10.5.
Apart from the fact that the newer edition has pretty red headings, can anybody discern a difference there? If you go to §5.5 both versions permit boxing and unboxing, in Java7 possibly with an associated widening conversion. I can still see no explanation for the different behaviour.15.21.3. Reference Equality Operators == and !=
If the operands of an equality operator are both of either reference type or the null type, then the operation is object equality.
It is a compile-time error 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.
At run-time, the result of == is true if the operand values are both null or both refer to the same object or array; otherwise, the result is false.
The result of != is false if the operand values are both null or both refer to the same object or array; otherwise, the result is true.
While == may be used to compare references of type String, such an equality test determines whether or not the two operands refer to the same String object. The result is false if the operands are distinct String objects, even if they contain the same sequence of characters (§3.10.5). The contents of two strings s and t can be tested for equality by the method invocation s.equals(t).
Wout Er wrote:which, at least to me, seems to indicate that what's underneath is only applicable if that condition is met and therefore not when one of both operands is a primitive.
These are not the droids you are looking for. Perhaps I can interest you in a tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|