8 ms·

new Integer(10) == new Integer(10) // true Before value classes this would always be false. The only time comparing Integer objects with == could be true is if

new Integer(10) == new Integer(10) // true Before value classes this would always be false. The only time comparing Integer objects with == could be true is if Integer object was create by going through Integer.valueOf (or obviously if they were the same object reference.) By default the cached values where -127 to 127, but that is tuneable at runtime. https://github.com/openjdk/jdk/blob/jdk-27%2B27/src/java.base/share/classes/java/lang/Integer.java#L988 https://github.com/openjdk/jdk/blob/jdk-27%2B27/src/java.bas...

tsimionescu 3mo ago
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).
- papercrane 3mo ago
  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: iconst_1 invokestatic java/lang/Integer.valueOf:(I)Ljava/lang/Integer
  - tsimionescu 3mo ago
    Sure, I was just talking about Java syntax, not the bytecode internals.
jmyeet 3mo ago
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-boxing-in-java https://stackoverflow.com/questions/3130311/weird-integer-bo... [2]: https://dev.to/marzuk16/understanding-integer-caching-in-java-the-hidden-optimization-you-mightve-missed-ggi https://dev.to/marzuk16/understanding-integer-caching-in-jav...
- xxs 3mo ago
  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

tsimionescu 3mo ago

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).

papercrane 3mo ago
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: iconst_1 invokestatic java/lang/Integer.valueOf:(I)Ljava/lang/Integer
- tsimionescu 3mo ago
  Sure, I was just talking about Java syntax, not the bytecode internals.

jmyeet 3mo ago

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-boxing-in-java https://stackoverflow.com/questions/3130311/weird-integer-bo... [2]: https://dev.to/marzuk16/understanding-integer-caching-in-java-the-hidden-optimization-you-mightve-missed-ggi https://dev.to/marzuk16/understanding-integer-caching-in-jav...

xxs 3mo ago
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