[mperor]

Note: tests were not run locally. The build requires JDK 25 via the Gradle toolchain, and the foojay toolchain resolver is blocked by this environment's network policy (403 from the proxy), so JDK 25 could not be provisioned. The boxing/caching semantics in this test were manually verified under JDK 21, which are identical to JDK 25 for this feature. CI will verify. Opened as a draft until that's confirmed.

What you'll learn

• Why Integer a = 127, b = 127; a == b is true, but the same comparison fails for 128
• That autoboxing goes through Integer.valueOf, which caches -128..127, while the deprecated new Integer(...) constructor never does
• That Long, Short and Byte share the same -128..127 cache, Character caches 0..127, and Double/Float are never cached
• Why equals(), not ==, is the correct way to compare boxed values, and why unboxing a null reference throws NullPointerException

Why it matters

Relying on == for boxed numbers works by accident for small values and breaks silently once values leave the cached range — a classic source of subtle bugs in real code.

Read more

Integer.valueOf Javadoc

Quiz

What does the following print?

Integer a = 100, b = 100;
Integer c = 200, d = 200;
System.out.println((a == b) + " " + (c == d));

Answer

`true false` — 100 is inside the `Integer` cache's `-128..127` range, so `a` and `b` are the same cached instance. 200 is outside it, so `c` and `d` are distinct `Integer` objects even though they hold the same value.

Closes #88

[github-actions]

Test Results

274 tests  +8   271 ✅ +8   5s ⏱️ -1s
 79 suites +1     3 💤 ±0 
 79 files   +1     0 ❌ ±0 

Results for commit 421d843. ± Comparison against base commit 52ef489.

This pull request skips 1 and un-skips 1 tests.

pl.mperor.lab.java.design.pattern.creational.singleton.SingletonTest ‑ testLazyInitialized()

pl.mperor.lab.java.design.pattern.creational.singleton.SingletonTest ‑ testSerializationSafe()