The following is an abstract from K&B book page 236...Chap3...Assignments
Yikes! The equals() method seems to be working, but what happened with == and != ? Why is != telling us that i1 and i2 are different objects, when == is saying that i3 and i4 are the same object? In order to save memory, two instances of the following wrapper objects will always be == when their primitive values are the same: n Boolean n Byte n Character from \u0000 to \u007f (7f is 127 in decimal) n Short and Integer from -128 to 127
The above concept also applies to Long from -128 to 127... i.e Long ln = 1L; Long ln2 = 1L;
(ln==ln2) returns true
...then why its not included in the book..is it an errata...?
If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.
Note that type long is not included in this statement.
This does not mean that long values will not behave in this manner. As you've demonstrated, long values actually do behave this way on your platform. But this behavior is not guaranteed.
(Note that it's also not specified what will happen for values outside of this range. The wrapper objects are not required to be equal, but they're not required to be unequal either. The only behavior we can be certain of is what's covered by the JLS statement above.)
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Villains always have antidotes. They're funny that way. Here's an antidote disguised as a tiny ad: