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 3 days ago | parent [-]

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 3 days ago | parent | next [-]

> 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 3 days ago \| parent [-]
		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.

▲ tpm 3 days ago | parent | prev | next [-]

Yeah - it's a bit non-intuitive you can change the value of a number.

https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...

▲ J-Kuhn 2 days ago | parent | next [-]

Such hacks will slowly stop working (without explicitly allowing it from the command line.)

In this example, it would throw an IllegalAccessException, because java.base doesn't open java.lang.

	▲	vips7L 16 hours ago \| parent [-]
		Doesn’t field.setAccessible(true) already throw on a modern version?

▲ inigyou 3 days ago | parent | prev [-]

In Python 2 you could literally do

    True = False

and of course in JavaScript

    undefined = "a string"

	▲	swiftcoder 2 days ago \| parent [-]
		The terrifying part of this in Java, is that it applies program-wide, including to constants set before you changed the value

▲ 2 days ago | parent | prev [-]

[deleted]