When you run a Java program, three distinct pieces of software cooperate behind the scenes: the compiler, the class file format (bytecode), and the Java Virtual Machine. Understanding this pipeline demystifies both how Java achieves “Write Once, Run Anywhere” and why some Java concepts (like the JVM warming up) behave differently from a purely native-compiled language.

The compiler, javac, reads your .java source files and checks them for syntax errors and type errors. If everything checks out, it produces one .class file per class, containing bytecode — a compact, platform-neutral set of instructions. Bytecode is not native machine code for any particular CPU; it is an intermediate representation designed specifically to be portable.

When you run a program, the JVM’s class loader reads the relevant .class files into memory and runs a bytecode verifier over them. This verifier checks that the bytecode doesn’t do anything unsafe — like accessing memory it shouldn’t or violating type rules — before a single instruction executes. This is a key part of Java’s security model.

Finally, the JVM executes the bytecode. Early on, it interprets bytecode instructions one at a time. For code that runs frequently — hot loops, hot methods — the JVM’s Just-In-Time (JIT) compiler kicks in and translates that bytecode into native machine instructions for the actual CPU it’s running on, caching the result so future calls run at native speed.

A traditional compiled language (like C) compiles source code directly into native machine code for one specific operating-system-and-CPU combination; that binary won’t run anywhere else without recompiling. Java splits compilation into two stages precisely to avoid that limitation:

In short: the bytecode is universal, and the JVM is what adapts it to a specific machine at run time. That split is the entire mechanism behind “Write Once, Run Anywhere.”