[weinzierl]

If I understand this correctly then Integer becomes a value class and every instance of it loses its object identity.

I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me.

[agilob]

Java has a mechanism for Integer and Long objects caching using something that already looks like value object, cached objects can be compared using ==. hashCode of Integer already returns int, the boxed int value. Not much of value is lost.

[swiftcoder]

Of particular note, all 1-byte Integers are interned, there is a pool of small Integers from -127 <-> 127 which are reused whenever possible.

I learned this the hard way, when a C++ JNI extension I was working on accidentally overwrote the pooled value for zero, and all hell broke loose...

[agilob]

> Integers from -127 <-> 127

The cache can be extended on startup with env var `java.lang.Integer.IntegerCache.high `

https://github.com/openjdk/jdk/blob/cc278dbb8a1ca0754d584270...

[pwagland]

That is a nice piece piece of knowledge! We have an Integer cache in our product, and the only reason that it hangs around is that it caches 0..1024 instead of -127..128. By setting this value, we could simplify our code, ever so slightly.

[josefx]

Any project depending on Integer identity had years of warning that this change would come. Also given implicit primitive conversions and object pooling Integer isn't exaclty a prime candidate for object identity to begin with.

[ivolimmen]

As far as I understood this (plus future work) will make value classes work more like structs meaning it will save memory and align memory better for things like gRPC, etc.