A `.class` file is corrupted in transit — a byte gets flipped somewhere in the middle. What actually happens when `java` tries to load it, and why can this failure occur even for a file that `javac` produced correctly and nobody hand-edited?

java Greet does much more than "run that file": it finds the bytes through a classloader, then independently verifies the bytecode before running a single instruction — checking that it can't violate the type system or jump to an invalid instruction — and only then invokes main. That verification step doesn't trust that the bytes came from a well-behaved javac; it runs against every class file regardless of who or what produced it, specifically because the JVM has no way to know in advance whether a given file is what it claims to be. A corrupted file — one byte flipped, whether by a bad disk, a broken transfer, or an actual attacker — is exactly the case this step exists for: it fails verification (typically a VerifyError) before execution ever begins, rather than running a subtly wrong program.