Challenge 2: Fixing the 500 Comparison with .equals() — Possible Solution
====================================================================

BoxingDemo.java (continued):

public class BoxingDemo {
    public static void main(String[] args) {
        Integer c = 500;
        Integer d = 500;
        System.out.println("500 == 500:      " + (c == d));
        System.out.println("500 .equals 500: " + c.equals(d));
    }
}

Output:

    500 == 500:      false
    500 .equals 500: true

Explanation:
.equals() on Integer is overridden to compare the actual numeric VALUE
each object wraps, not the objects' identity in memory. It doesn't
matter whether 500 was cached or not, or whether `c` and `d` happen to
be the same object -- .equals() only asks "do these two objects
represent the same value," which is true here regardless of caching.

This is why .equals() works correctly and consistently across the
entire int range, while == only happens to "work" by accident for
values inside the -128..127 cache -- a fragile coincidence, not a
reliable comparison.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly resolves the gotcha the chapter names by showing
.equals() succeeding on exactly the value (500) that == failed on in
Challenge 1, and explains WHY: .equals() compares value, not
reference, so it's unaffected by whether the JVM happened to cache
that particular Integer.