Challenge 1: Comparing 100 vs. 500 with == — Possible Solution
====================================================================

BoxingDemo.java:

public class BoxingDemo {
    public static void main(String[] args) {
        Integer a = 100;
        Integer b = 100;
        System.out.println("100 == 100: " + (a == b));

        Integer c = 500;
        Integer d = 500;
        System.out.println("500 == 500: " + (c == d));
    }
}

Output:

    100 == 100: true
    500 == 500: false

Explanation:
100 falls inside Java's cached Integer range (-128 to 127), so both
`a` and `b` are autoboxed to the SAME cached Integer object -- == is
comparing that one object's reference to itself, which is true.

500 falls outside the cached range, so each `Integer c = 500` and
`Integer d = 500` triggers a fresh, separate autoboxing allocation --
two distinct objects with the same value. == compares references, not
values, so two different objects holding the same number compare as
unequal.

WHY THIS WORKS AS AN ANSWER
------------------------------
This reproduces the chapter's own -128..127 caching boundary exactly
at its edge (100 inside, 500 outside) and explains the result in terms
of reference identity rather than value, matching the chapter's own
== vs. .equals() distinction.