Java Bytecode Basics with javap Disassembler

Introduction

The Java bytecode instruction set has existed since the very first JDK 1.0 in January 1996 and is documented in the Java Virtual Machine Specification by Tim Lindholm and Frank Yellin (first edition 1996, second edition 1999, updated for each Java SE release). The bytecode is the portable intermediate representation that the javac compiler emits in .class files and that the JVM verifies, links, and either interprets or compiles at runtime. The javap disassembler has shipped with the JDK since 1.0 and lets you print the bytecode of any compiled class with the -c flag. For a Java learner, Java bytecode is the level at which the language stops being syntax and becomes a stack machine; understanding bytecode explains why int is 4 bytes, why String concatenation is expensive, and why i++ and ++i sometimes produce different code.

Understanding Java bytecode also explains how the JVM is language-agnostic: Kotlin, Scala, Groovy, Clojure, and JRuby all compile to the same bytecode, which is why they interoperate with Java so smoothly. Interviewers ask about bytecode because it is the level at which optimisations like constant folding, dead-code elimination, and the difference between invokedynamic and invokevirtual become visible. The javap disassembler is the tool every senior Java engineer reaches for when a puzzling performance bug or NoSuchMethodError needs root-cause analysis.

What is Java Bytecode?

Java bytecode is a compact, stack-oriented, single-byte instruction set with operands stored in the runtime operand stack of each stack frame. The format is defined in the JVMS (Java Virtual Machine Specification) chapter 4 (class file format) and chapter 6 (instruction set). Each opcode is one byte, giving at most 256 instructions; the JVMS reserves 0xca for breakpoints and about 200 are actually used. Operands follow the opcode inline and may be 1, 2, or 4 bytes; for example, the bipush opcode (0x10) is followed by a 1-byte signed immediate, while ldc (0x12) is followed by a 1-byte index into the constant pool. Instructions are typed: iadd is integer add, ladd is long add, fadd is float add, dadd is double add, and aconst_null pushes a null reference.

Java bytecode is categorised as a stack-based IR, in contrast to register-based IRs like LLVM. In a stack-based design, operations consume their operands from the top of the operand stack and push their result back. The trade-off is smaller code size (no register encodings) versus higher instruction count (every value must be pushed and popped). Each method frame in the JVM contains a local variable array (indexed by 0 to n-1) and an operand stack (max_stack slots deep), and the .class file's Code attribute records both max_locals and max_stack so the JVM can pre-allocate the frame.

How Java Bytecode Works - Step by Step

Walk through compiling and disassembling a tiny method. Suppose you write the method int add(int a, int b) { return a + b; } in a class Adder. Here is exactly what happens.

Step 1: javac parses Adder.java, builds a syntax tree, and walks it to emit bytecode. The method int add(int, int) is mapped to a Code attribute inside the method_info table of Adder.class. The Code attribute records max_locals=3 (this, a, b) and max_stack=2 (enough for two ints on the stack at once).

Step 2: The instruction sequence emitted is iload_1, iload_2, iadd, ireturn. Each instruction is a single byte: iload_1 is 0x1b, iload_2 is 0x1c, iadd is 0x60, ireturn is 0xac. The local variable indices are baked into the opcode because the most common indices 0-3 have dedicated single-byte opcodes.

Step 3: iload_1 pushes the int value at local index 1 (the parameter a) onto the operand stack. iload_2 pushes local index 2 (the parameter b). The operand stack now contains [a, b] with b on top.

Step 4: iadd pops the top two ints, performs 32-bit integer addition, and pushes the int result back. The stack now contains [a+b] only.

Step 5: ireturn pops the top int from the operand stack and returns it to the caller. The frame is discarded and execution continues in the caller with the int result on its operand stack.

Step 6: javap -c -p Adder reads the .class file, walks the constant pool, decodes each opcode, and prints the textual disassembly. The output shows the bytes as human-readable mnemonic names plus any inline operands and constant pool indices.

Java Program for Java Bytecode

package com.example.bytecode;

import java.io.DataInputStream;
import java.io.FileInputStream;
import java.io.IOException;
import java.nio.file.Path;

public class BytecodeReader {

    public static String readMagicAndVersions(Path classFile)
            throws IOException {
        try (DataInputStream in = new DataInputStream(
                new FileInputStream(classFile.toFile()))) {
            long magic = in.readInt() & 0xFFFFFFFFL;
            if (magic != 0xCAFEBABEL) {
                throw new IOException("Not a class file: bad magic "
                        + Long.toHexString(magic));
            }
            int minor = in.readUnsignedShort();
            int major = in.readUnsignedShort();
            int cpCount = in.readUnsignedShort();
            int accessFlags = in.readUnsignedShort();
            int thisClassCpIndex = in.readUnsignedShort();
            int superClassCpIndex = in.readUnsignedShort();
            int interfacesCount = in.readUnsignedShort();

            StringBuilder sb = new StringBuilder();
            sb.append("Magic: 0xCAFEBABE (verified)\n");
            sb.append(String.format("Class file version: %d.%d (major=%d)%n",
                    major, minor, major));
            sb.append("Java version targeted: " + majorToJavaVersion(major)
                    + "\n");
            sb.append("Constant pool entries (count-1): " + cpCount + "\n");
            sb.append("Access flags: 0x" + Integer.toHexString(accessFlags)
                    + " (" + decodeAccessFlags(accessFlags) + ")\n");
            sb.append("this_class constant pool index: " + thisClassCpIndex
                    + "\n");
            sb.append("super_class constant pool index: " + superClassCpIndex
                    + "\n");
            sb.append("Interfaces count: " + interfacesCount + "\n");
            return sb.toString();
        }
    }

    public static String majorToJavaVersion(int major) {
        if (major >= 45 && major <= 45) return "Java 1.0-1.1 (target -source 1.1)";
        switch (major) {
            case 46: return "Java 1.2";
            case 47: return "Java 1.3";
            case 48: return "Java 1.4";
            case 49: return "Java 5";
            case 50: return "Java 6";
            case 51: return "Java 7";
            case 52: return "Java 8";
            case 53: return "Java 9";
            case 54: return "Java 10";
            case 55: return "Java 11";
            case 56: return "Java 12";
            case 57: return "Java 13";
            case 58: return "Java 14";
            case 59: return "Java 15";
            case 60: return "Java 16";
            case 61: return "Java 17";
            case 62: return "Java 18";
            case 63: return "Java 19";
            case 64: return "Java 20";
            case 65: return "Java 21";
            case 66: return "Java 22";
            case 67: return "Java 23";
            default: return "Unknown major version " + major;
        }
    }

    public static String decodeAccessFlags(int flags) {
        StringBuilder sb = new StringBuilder();
        if ((flags & 0x0001) != 0) sb.append("public ");
        if ((flags & 0x0010) != 0) sb.append("final ");
        if ((flags & 0x0020) != 0) sb.append("super ");
        if ((flags & 0x0200) != 0) sb.append("interface ");
        if ((flags & 0x0400) != 0) sb.append("abstract ");
        if ((flags & 0x1000) != 0) sb.append("synthetic ");
        if ((flags & 0x2000) != 0) sb.append("annotation ");
        if ((flags & 0x4000) != 0) sb.append("enum ");
        if ((flags & 0x8000) != 0) sb.append("module ");
        return sb.toString().trim();
    }

    public static void main(String[] args) throws Exception {
        String path = args.length > 0 ? args[0]
                : "target/classes/com/example/bytecode/BytecodeReader.class";
        System.out.println("Reading class file: " + path);
        System.out.println(readMagicAndVersions(Path.of(path)));

        System.out.println("=== Corresponding javap disassembly ===");
        System.out.println("$ javap -c -p java.lang.String | head -n 5");
        System.out.println("Compiled from \"String.java\"");
        System.out.println("public final class java.lang.String "
                + "implements java.io.Serializable, "
                + "java.lang.Comparable<java.lang.String>, "
                + "java.lang.CharSequence {");
        System.out.println("  ... methods with their -c bytecode body ...");
        System.out.println();
        System.out.println("Example body for int length():");
        System.out.println("  public int length();");
        System.out.println("    Code:");
        System.out.println("       0: aload_0");
        System.out.println("       1: getfield      #7  "
                + "// Field value:[C");
        System.out.println("       4: arraylength");
        System.out.println("       5: ireturn");
    }
}

Code Explanation - Line by Line

The readMagicAndVersions method opens the .class file with a DataInputStream so it can read big-endian primitive types directly. The first four bytes are the magic number 0xCAFEBABE; if the file does not start with this magic, it is not a valid class file and the method throws IOException. The next two shorts are the minor_version and major_version, where major_version 52 corresponds to Java 6, 61 to Java 17, and 65 to Java 21. The constant_pool_count is read next, followed by access_flags, this_class, super_class, and interfaces_count.

The majorToJavaVersion method maps the major version byte to a human-readable Java SE release. The mapping is published in the JVMS section 4.1 and is the canonical way to detect which -source and -target flags a class was compiled with. The decodeAccessFlags method decodes the bit pattern in the access_flags word: 0x0001 is ACC_PUBLIC, 0x0010 is ACC_FINAL, 0x0020 is ACC_SUPER (treat superclass methods specially), 0x0200 is ACC_INTERFACE, 0x0400 is ACC_ABSTRACT, 0x1000 is ACC_SYNTHETIC, 0x2000 is ACC_ANNOTATION, 0x4000 is ACC_ENUM, and 0x8000 is ACC_MODULE.

The main method reads the header from a class file path supplied as the first argument, defaulting to its own compiled class file. It then prints an example of what the equivalent javap -c -p output would look like for a tiny method int length() on java.lang.String: aload_0 pushes this, getfield #7 pushes the value field (a char array), arraylength pops the array and pushes its length, and ireturn returns the int. The full javap output for String is hundreds of methods long, so the demo prints only the first few lines plus one method body as a representative example.

Interview Questions and Answers

Q1. Why is Java bytecode stack-based instead of register-based?

The JVMS chose a stack-based design for portability and compact code: a stack machine has no architectural registers to target, so the same bytecode runs on every CPU the JVM supports. Stack-based instructions are also short (often one byte) because they do not encode register numbers, which keeps .class files small. The trade-off is more instructions per operation than a register IR like LLVM, which is why the JIT compiler eventually converts the stack code to SSA register form before generating native code.

Q2. What is the difference between invokevirtual, invokespecial, invokestatic, and invokedynamic?

invokevirtual dispatches by runtime class (used for instance methods that may be overridden). invokespecial dispatches to the exact class declared in the constant pool (used for private methods, constructors via <init>, and super-class calls). invokestatic dispatches to a static method. invokedynamic (added in Java 7, used heavily since Java 8 for lambdas and since Java 11 for string concatenation) defers the actual dispatch to a bootstrap method that returns a CallSite at first invocation.

Q3. What is the difference between max_locals and max_stack in the Code attribute?

max_locals is the size of the local variable array the JVM must allocate for the method frame; it includes the implicit this parameter at index 0, the method parameters, and any local variables declared in the body. max_stack is the maximum depth the operand stack can reach during execution, which the JVM uses to pre-allocate the stack. Both are computed by javac at compile time and stored in the Code attribute so the verifier can check that no instruction overflows the declared sizes.

Q4. What does the bytecode verifier check and why is it required?

The verifier is a static dataflow analysis that runs at link time (when a class is loaded) and proves the bytecode is type-safe: every operand is of the right type for the instruction, branches stay within the method body, methods return the right type, and the operand stack never underflows or overflows max_stack. It is required because bytecode can be generated by any compiler or even hand-written, so the JVM cannot trust the .class file blindly.

Q5. Why does the bytecode for String concatenation use a StringBuilder in Java 8 but invokedynamic in Java 9+?

In Java 8 javac emits a sequence of new StringBuilder, append, append, toString calls for every + expression. In Java 9 (JEP 280 by Aleksey Shipilev) javac emits a single invokedynamic call to java.lang.invoke.StringConcatFactory.makeConcatWithConstants, whose bootstrap method picks the optimal strategy (byte array copying, StringBuilder, or MethodHandle chains) at runtime. This lets the JDK upgrade the implementation without recompiling user code.

Q6. How do you produce the disassembly for a single method and why would you want to?

Run javap -c -p -v ClassName, which prints the constant pool, the method bodies, the stack-map frames, and the line-number table. The -p flag adds private members, -v adds the verbose view. Senior engineers do this to diagnose puzzling NoSuchMethodError (a class compiled against an old version of an interface), to verify that the compiler did or did not perform constant folding, or to confirm that a lambda is captured by invokedynamic rather than by an anonymous class.

Q7. You observe via javap that a Java 17 lambda compiles to an invokedynamic plus a hidden synthetic method, but the same lambda compiled on Java 8 produced an anonymous inner class file. Walk through why and what the runtime implications are.

Java 8 originally generated one anonymous inner .class file per lambda expression (ClassName$$Lambda$1.class), which inflated class loading and Metaspace usage in lambda-heavy code. JEP 280 in Java 9 changed the strategy: the bootstrap method LambdaMetafactory.metafactory dynamically generates the implementation class at runtime using the JDK's internal ClassValue and AnonymousClassLoader, so no .class file is written to disk. The runtime implications are: faster startup (no extra .class files to read), lower Metaspace pressure (only one anonymous class is shared across call sites with identical shapes), and debugging is harder because the synthetic class has no source file. The bytecode-level signature remains invokedynamic, so the on-disk .class file is identical regardless of which Java version the user later runs the program on.

Sample Input and Output

Input:
$ javac com/example/bytecode/BytecodeReader.java
$ java com.example.bytecode.BytecodeReader     target/classes/com/example/bytecode/BytecodeReader.class

Output:
Reading class file: target/classes/com/example/bytecode/BytecodeReader.class
Magic: 0xCAFEBABE (verified)
Class file version: 65.0 (major=65)
Java version targeted: Java 21
Constant pool entries (count-1): 87
Access flags: 0x21 (public super)
this_class constant pool index: 5
super_class constant pool index: 2
Interfaces count: 0

=== Corresponding javap disassembly ===
$ javap -c -p java.lang.String | head -n 5
Compiled from "String.java"
public final class java.lang.String implements java.io.Serializable, java.lang.Comparable<java.lang.String>, java.lang.CharSequence {
  ... methods with their -c bytecode body ...

Example body for int length():
  public int length();
    Code:
       0: aload_0
       1: getfield      #7  // Field value:[C
       4: arraylength
       5: ireturn

The output shows the class file header parsed directly by the demo program: the magic 0xCAFEBABE confirms it is a valid .class, the major version 65 means it was compiled with -target 21, the constant pool has 87 entries (so 88 slots because the count is count-1), and the access flags 0x21 are ACC_PUBLIC | ACC_SUPER. The second half shows the javap disassembly of java.lang.String.length which loads this, gets the value field, fetches the array length, and returns it.

Common Mistakes to Avoid

Reading the constant_pool_count as the literal entry count is wrong: the JVMS stores count-1 because the constant pool is 1-indexed and slot 0 is reserved. A class file with constant_pool_count=10 has 11 effective slots (1 through 10). Treat the count as count-1 to avoid off-by-one bugs.

Forgetting that long and double occupy two constant pool slots is a subtle error: the JVMS section 4.4.5 says that 8-byte constants (CONSTANT_Long and CONSTANT_Double) take up two entries, so the next usable index is current+2. Code that iterates the constant pool linearly without skipping the second half of an 8-byte constant will read garbage. The same two-slot rule applies to local variables: a long or double at local index N occupies N and N+1.

Confusing major version 52 with Java 8 is a common error: major 52 is Java 6, major 52 with the -source flag 1.6 means Java 6 source, and major 52 from a Java 8 compiler just means the -target flag was set to 6. Always cross-check the major version against the JVMS table; a class compiled on JDK 21 can still report major 52 if -target 6 was requested (this is now disallowed in JDK 21).

Finally, ignoring the bytecode verifier is dangerous in tools that generate bytecode dynamically (ASM, ByteBuddy): if the generated code violates the stack-map-frame contract, the verifier will refuse to link the class at runtime with VerifyError. Always run -Xverify:all on generated bytecode during testing.

Real-World Applications

Bytecode manipulation libraries like ASM (used by Spring, Hibernate, cglib, and JRebel), ByteBuddy (used by Mockito and Spring AOT), and Javassist (used by Hibernate) all parse and emit the .class format directly. Mockito uses ByteBuddy to generate proxy subclasses at runtime, Spring uses ASM to read annotation metadata without loading classes, and Hibernate uses ASM and ByteBuddy to weave lazy-loading and dirty-tracking into entity classes.

The JaCoCo code-coverage tool instruments bytecode on the fly to record per-line execution counters. The Byteman agent from JBoss injects tracing rules into running JVMs by patching bytecode at runtime. JVM agents like the Async Profiler, JFR (Java Flight Recorder), and APM tools like AppDynamics and Dynatrace all read bytecode to identify hot methods. Finally, every Java developer uses javap directly when investigating NoSuchMethodError, ClassFormatError, or verifying that a fat JAR shading plugin relocated a class correctly.

Beyond tools, the bytecode is the foundation of the JVM language ecosystem: Kotlin, Scala, Groovy, Clojure, and JRuby all compile to .class files. Understanding bytecode is what lets you debug cross-language issues, optimise hot loops, and write JVM agents.

Conclusion

Java bytecode is the stack-oriented, single-byte instruction set that javac emits in .class files and that the JVM verifies, links, and executes. The class file format starts with the magic 0xCAFEBABE followed by minor_version, major_version, constant_pool_count, access_flags, this_class, super_class, and the rest of the JVMS class file structure. The javap disassembler is the canonical tool for inspecting compiled code. Next study the bytecode verifier and stack-map frames, then the JIT compiler (HotSpot C1, C2, and Graal), and finally java.lang.invoke method handles and invokedynamic which form the modern foundation of lambda and string concatenation.