Inspect Java Bytecode with javap -c

Reading javap Output

\`javap -c\` disassembles \`.class\` files into JVM bytecode mnemonics. Every JDK ships it, and it is the first tool Java engineers use to verify what \`javac\` actually emitted.

Common Opcodes

Stack operations and calls dominate simple methods:

• \`iconst_0\` .. \`iconst_5\`: push small integer constants
• \`iload_0\` / \`istore_0\`: move ints between locals and stack
• \`iadd\`: pop two ints, push sum
• \`invokestatic\` / \`invokevirtual\`: static versus virtual dispatch
• \`ldc\`: load a constant-pool entry (strings, classes, numbers)

For example, \`System.out.println("hi")\` shows \`getstatic\` for the \`PrintStream\`, \`ldc\` for the string, then \`invokevirtual\` on \`println\`.

Verbose mode (\`javap -v\`) adds the constant pool, stack map tables, and line numbers for debugging.

Design Notes

Compare `javap -c` output before and after a one-line Java source change to see what javac actually altered. Optimizations like string concatenation lowering are visible only at bytecode level.

For This Exercise

This exercise asks you to document sample \`javap -c\` output for a simple Java class. You will label opcodes and explain how source-level statements map to stack instructions.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.