Challenge 3: Why Java's Primitives Are "Rust-like," Not "C-like" — Possible Solution
====================================================================

c1-2's own material establishes that C only guarantees a MINIMUM size
for int -- the standard requires int be at least 16 bits, but the
actual size is left to the platform/compiler, and in practice is
commonly 32 bits on modern systems, without that being a portable
guarantee a C programmer can rely on across every platform.

Java's primitives take the opposite approach: every one of the eight
primitive types -- byte, short, int, long, float, double, char,
boolean -- has an EXACT size fixed by the JVM specification itself,
identical on every platform running any conforming JVM. An int is
always 32 bits, whether the program runs on Windows, Linux, or macOS,
on x86 or ARM. There is no platform-dependent variation to account
for at all.

Rust makes the same kind of guarantee -- its integer types (i32, u8,
i64, etc.) are exact-width by definition, not minimum-width, which is
exactly why the chapter calls Java's primitives "Rust-like" rather
than "C-like": Java sides with Rust's exact-guarantee model, not with
C's minimum-only, platform-dependent model, even though Java's own
class-based structure and general feel otherwise sits closer to C++.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly cites c1-2's minimum-vs-exact distinction for C's int
and shows Java's primitives satisfy the exact-guarantee side of that
same distinction, which is the specific, narrow sense in which the
chapter calls Java's type sizes "Rust-like" rather than "C-like" --
not a claim that Java and Rust are alike in general.