Consider the following snippet:
int i = 99999999; byte b = 99; short s = 9999; Integer ii = Integer.valueOf(9); // should be within cache System.out.println(new Integer(i) == i); // "true" System.out.println(new Integer(b) == b); // "true" System.out.println(new Integer(s) == s); // "true" System.out.println(new Integer(ii) == ii); // "false"
It's obvious why the last line will ALWAYS prints "false"
: we're using ==
reference identity comparison, and a new
object will NEVER be ==
to an already existing object.
The question is about the first 3 lines: are those comparisons guaranteed to be on the primitive int
, with the Integer
auto-unboxed? Are there cases where the primitive would be auto-boxed instead, and reference identity comparisons are performed? (which would all then be false
!)
Yes. JLS §5.6.2 specifies the rules for binary numeric promotion. In part:
When an operator applies binary numeric promotion to a pair of operands, each of which must denote a value that is convertible to a numeric type, the following rules apply, in order, using widening conversion (§5.1.2) to convert operands as necessary:
If any of the operands is of a reference type, unboxing conversion (§5.1.8) is performed.
Binary numeric promotion applies for several numeric operators, including "the numerical equality operators == and !=."
JLS §15.21.1 (Numerical Equality Operators == and !=) specifies:
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).
In contrast, JLS §15.21.3 (Reference Equality Operators == and !=) provides:
If the operands of an equality operator are both of either reference type or the null type, then the operation is object equality
This fits the common understanding of boxing and unboxing, that's it only done when there's a mismatch.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With