Java Compiler, Java Interpreter

javac is the compiler (source to bytecode) and the JVM is the interpreter (bytecode to execution, with JIT for speed): two tools, two jobs, one running program.

9 min read · 10 cards · 2 checks

Read in: English · हिन्दी · ગુજરાતી


Theory

Two commands, two mysteries

Your first BookBridge session in the lab looks like this:

javac BookBridge.java

java BookBridge

Two different commands. The first one prints nothing at all if it succeeds. The second one actually runs your program. Most students type these for 3 years without asking what each one really does, and then the exam asks exactly that: explain the Java compiler and interpreter.

Theory

The scriptwriter and the narrator

Think of a story written in Gujarati that must reach listeners in every state.

javac is the scriptwriter: it translates your story once into a standard script (bytecode) that no listener speaks natively.

The JVM is the local narrator: in each state, a narrator reads that standard script and performs it live in the local language. One script, many narrators. The writing happens once; the narration happens on every machine, every run.

Theory

The two tools, formally

Java compiler (javac): translates human-readable source code (BookBridge.java) into bytecode (BookBridge.class), the standard instruction set of the Java Virtual Machine. This happens once, before running.

Java interpreter (the JVM): loads the .class file and executes bytecode instructions one by one on the actual machine. For code that runs repeatedly, its JIT (just-in-time) compiler translates hot bytecode into native machine code on the fly, so long-running programs speed up.

So Java is both compiled and interpreted: compiled to bytecode, interpreted (plus JIT) by the JVM.

Practical

BookBridge.java, the first listing

public class BookBridge {
    public static void main(String[] args) {
        System.out.println("== BookBridge Library ==");
        System.out.println("Books ready to issue: 12");
    }
}

Follow along

From source to running program

  1. Write BookBridge.java The public class name must exactly match the filename: public class BookBridge lives in BookBridge.java.
  2. Compile: javac BookBridge.java javac checks the code and produces BookBridge.class (bytecode). Success prints nothing; errors stop everything here.
  3. Run: java BookBridge Give the CLASS name, not the filename. The JVM loads BookBridge.class, finds main, and executes.

Quiz

What exactly does the javac command produce?

  1. A .exe file of native machine code, ready to run directly
  2. A .class file of bytecode, which needs a JVM to execute
  3. Nothing; javac runs the program directly from the source file
  4. A new JVM customised for this program
Show the answer

A .class file of bytecode, which needs a JVM to execute

javac stops at bytecode: a .class file no CPU can run directly, which is exactly why every machine needs a JVM. Option A describes a C compiler's output. Option C confuses javac with the java command (and even java does not run source in this syllabus's model). Option D is nonsense with a serious face: the JVM is installed once per machine, never generated per program.

Think first

Spot your friend's mistake

Your friend compiles successfully, then types java BookBridge.class and gets an error about not finding the class. Before tapping: what went wrong?

Show the answer

The java command takes a class name, not a filename. Typing java BookBridge.class makes the JVM search for a class literally named "class" inside a package named "BookBridge", which does not exist. The correct command is java BookBridge: the JVM itself appends .class when it looks for the bytecode file. Compile with the filename, run with the class name.

Watch out

Where marks leak in this answer

Writing "Java is an interpreted language" alone loses the design point: it is compiled to bytecode first, then interpreted. Always present both stages.

And do not forget JIT in a full-marks answer: the JVM does not stay a slow line-by-line interpreter; it compiles frequently executed bytecode to native code during the run. JIT is the reason modern Java performance is close to C++ for long-running programs.

Theory

Connect it backward and forward

This 2-stage pipeline is the machinery behind "write once, run anywhere" from the previous lesson: javac makes the travelling bytecode, the JVM is the local runner. Contrast with BCA204's Python, where you never ran a separate compile command, and BCA104's C, where compilation went straight to machine code. Every BookBridge program this semester goes through exactly these 2 commands.

Summary

Key takeaways

  • javac = the Java compiler: .java source in, .class bytecode out, once before running.
  • The JVM = the Java interpreter: loads bytecode and executes it on the local machine.
  • JIT inside the JVM compiles hot bytecode to native code at run time, for near-native speed.
  • Java is both compiled (to bytecode) and interpreted (by the JVM); say both in the exam.
  • Compile with the filename (javac BookBridge.java), run with the class name (java BookBridge).
  • The public class name must match the filename exactly.
  • Memory hook: the scriptwriter writes once, the narrator performs everywhere.

Study this properly

This page is the lesson to read. In Gri-Learn the same topic is a graded deck: the self-checks are scored and your weak topics are tracked. Free to start.

Start this topic

Already have an account? Sign in

More from Introduction to Java

Gri-Learn · syllabus-mapped B.C.A. lessons in English, Hindi and Gujarati