Autoboxing Irregularities in Java: Investigating the Mysterious Comparisons
Java's autoboxing feature automatically converts primitive values into their corresponding wrapper class objects. However, a peculiar behavior arises when comparing two such objects.
Consider the following code snippet:
public class Scratch { public static void main(String[] args) { Integer a = 1000, b = 1000; System.out.println(a == b); // false Integer c = 100, d = 100; System.out.println(c == d); // true } }
The output perplexes us: the first comparison yields false, while the second returns true. Why is this so?
Unveiling the Mystery
The second line of output is guaranteed by the Java Language Specification (JLS). Section 5.1.7 states that primitive values within specific ranges, including integers between -128 and 127, are always boxed into identical objects.
If the value p being boxed is ... an int or short number between -128 and 127, then ... r1 == r2.
This ensures that commonly used values are consistently boxed as indistinguishable objects.
Ambiguity in the First Comparison
In contrast, the first comparison is not explicitly guaranteed by the JLS. While the specification allows implementations to cache objects within a range, it does not enforce it.
Therefore, the behavior of comparing larger integers as objects is implementation-specific. In this case, it appears that the runtime environment assigns distinct references to 'a' and 'b,' resulting in 'false' being printed.
Conclusion
Java's autoboxing provides convenience but also quirks when comparing certain primitive values. While values within a defined range are guaranteed to share identities, larger integers may behave differently depending on implementation choices. This knowledge helps us avoid unexpected behavior and stay in control of object comparisons in Java.
The above is the detailed content of Why Does Java's Autoboxing Produce Inconsistent Results When Comparing Integer Objects?. For more information, please follow other related articles on the PHP Chinese website!