new Integer(10) == new Integer(10) // true
https://github.com/openjdk/jdk/blob/jdk-27%2B27/src/java.bas...
It could also be true if the instances were created through auto-boxing (e.g. arrayList.add(10); arrayList.add(10); arrayList.get(0) == array List.get(1) //would return true, but false if you used 1000 instead of 10).
Yes, because auto-boxing is just compiling to Integer.getValue under the hood, the bytecode for Integer.getValue(1) and ((Integer) 1) is the same. They'll both compile to something like:
Sure, I was just talking about Java syntax, not the bytecode internals.
So you've made my point in showing how complex this is because you're incorrect [1][2]:
> By default, Java maintains a cache of Integer objects for values between -128 and +127.
[1]: https://stackoverflow.com/questions/3130311/weird-integer-bo...
[2]: https://dev.to/marzuk16/understanding-integer-caching-in-jav...
it's easier to remember that it originated from the Byte range, where all bytes could be kept in. Character didn't have negative values so it did [0-128) instead. Long and Short are the same as Byte.
Years before the autoboxing/Integer.valueOf() caching stuff (and before generics), (I) used to have IntegerProvider that did similar stuff to higher ranges. Personally, I have considered autoboxing on integers net-negative for Java