What is the bytecode that a Java compiler emits into .class files, and why does the JVM execute that form instead of executing source text directly or compiling straight to native machine code?

## What a .class file actually contains When you compile `Foo.java`, the output is `Foo.class` — a binary file in a format fixed by the JVM specification. It is not "compressed Java source" and not machine code. Its main parts are: - a **magic number** (`0xCAFEBABE`) and a class-file version; - a **constant pool**: a table of every string literal, class name, field name, method name and descriptor the class refers to, so instructions can refer to these by index instead of repeating text; - access flags, the superclass and interfaces; - **field and method tables**; each non-abstract method carries a `Code` attribute; - inside `Code`: the actual **bytecode array**, the maximum operand stack depth, the number of local-variable slots, exception-handler ranges, and optional debug attributes (line numbers, local variable names). The bytecode array is a sequence of instructions. Each instruction begins with a single-byte **opcode** (hence "bytecode"), optionally followed by operand bytes. There are around 200 defined opcodes, which is why one byte suffices. Examples: `iconst_1` (push int 1), `iload_2` (push local slot 2 as an int), `iadd` (pop two ints, push their sum), `getfield #7` (pop an object reference, push a field named by constant-pool entry 7), `invokevirtual #12`, `areturn`. ## Why an intermediate form at all **Portability.** A native compiler must commit to an instruction set, register file, calling convention and OS ABI. Bytecode commits to none of them: it targets an abstract machine defined on paper. Shipping bytecode means shipping one artifact for every platform that has a JVM. The famous slogan "write once, run anywhere" is really "compile once to bytecode, and let each platform's JVM deal with its own CPU". **Verifiability and safety.** Because bytecode is typed and structured, the JVM can run a **verifier** over a class before executing it: it checks that the operand stack never underflows or overflows the declared maximum, that types match the instructions applied to them, that jumps land on instruction boundaries inside the method, and that `final` classes are not subclassed. Native machine code cannot be checked that way in any practical sense. This is what made downloading and running untrusted code plausible in the first place. **Language neutrality.** The JVM knows nothing about Java syntax. Its contract is the classfile format. Anything that emits a valid classfile — Kotlin, Scala, Groovy, Clojure, a compiler you write this afternoon — runs on the JVM and interoperates with Java libraries, because at run time everything is just classes, methods and descriptors. **Compactness and late binding.** Bytecode is small and, crucially, symbolic: a call site names the target as `com/acme/Service.run:()V` rather than as an address. The JVM resolves those symbolic references lazily at run time, which is what makes dynamic linking, class loading and hot-swapping-style tooling possible at all. A statically linked native binary has no equivalent flexibility. ## What it costs Bytecode is not executable by the CPU. Something must bridge the gap: 1. The **interpreter** reads one instruction at a time and performs its effect. This starts instantly — no compile pause — but every instruction costs decoding and dispatch overhead on top of the work it represents. 2. The **JIT compiler** translates methods that prove to be hot into optimized native code, using profile data gathered while interpreting. So the JVM pays a translation cost that an ahead-of-time-compiled C binary does not. In exchange it gets portability, verification, and profile-guided optimization that can beat static compilation on real workloads because it sees actual behavior (which branches are taken, which receiver types actually appear). ## Common misreadings - "Bytecode is interpreted, so Java is slow." Bytecode is *initially* interpreted; hot code ends up as native machine code with inlining and register allocation. - "Bytecode is machine-independent, so it hides everything about the machine." It abstracts the instruction set, not the machine model — data races, memory visibility and 64-bit value handling are governed by the Java memory model, not erased by bytecode. - "The .class file is obfuscated/compiled beyond recovery." It retains names, descriptors and often line numbers; `javap -c` prints it, and decompilers reconstruct near-source. Bytecode is a *portability* format, not a protection mechanism.