How a Java Program Compiles and Runs

Where you are: Week 0 review > How a Java program compiles and runs

Try This First

A folder holds two files after a classmate builds a program: Hello.java and Hello.class. One was typed by a person; the other was produced by a tool. Before reading on, decide which is which.

Before You Start

Check each box you can do from memory. A box you cannot check yet is not a problem; it points you to a quick refresher, not a grade.

• I can open a terminal (command prompt) on my computer and type a command.
• I can navigate to a folder on disk and list its files in a terminal.
• I can describe what a file extension (such as .java or .txt) tells you about a file.

What You Need To Walk In With

Walk into the next class able to state these:

• Source code is for people; bytecode is for the machine. You write .java; the Java Virtual Machine (JVM) runs .class.
• The compiler javac reads .java and produces .class. The launcher java runs the .class.
• The cycle is edit, compile, run. Change the source, and you must compile again before the change takes effect.
• A syntax error is caught at compile time (no .class is produced). A runtime error appears while the program runs. A logic error is wrong output with no crash.

You should be able to: name the file each tool produces or consumes, and say at which stage a given error is caught.

How It Works

A .java file is text a person can read. The computer cannot run it directly. The compiler (javac) reads the source, checks it against the rules of the language, and writes a second file, .class, which holds bytecode: instructions for the JVM rather than for one specific processor.

   Hello.java   --javac-->   Hello.class   --java-->   output
   (you write)              (bytecode)               (what runs)
        ^                        |
        |   edit and save        |   wrong output? fix the source
        +------------------------+

Running java Hello executes whatever Hello.class is on disk. If you change Hello.java and skip the compile step, the old .class runs and the change does not appear. An editor such as VS Code or IntelliJ runs javac for you when you press Run, which hides the step but does not remove it.

The compile step exists for two reasons:

• Early checking: a misspelled name or a type mismatch stops javac from producing a .class, so the mistake surfaces before the program ever starts.
• Portability: the same .class bytecode runs on any machine that has a JVM, whether Windows, macOS, or Linux.

The kit you install is the JDK (Java Development Kit). It contains javac (to compile) plus the JRE (Java Runtime Environment, enough to run but not compile). This course installs the full JDK.

Three kinds of error

A compiler message names the file, the line, the problem, and a caret at the column:

Hello.java:4: error: ';' expected
        System.out.println("hi")
                               ^

Fix the lowest-numbered error first, then compile again, because one mistake often produces several messages.

Worked Example: Predict, Then Check

public class Hello {
    public static void main(String[] args) {
        System.out.println("Year: 2026");
    }
}

You compile with javac Hello.java, then run java Hello. Predict the output before reading on.

Year: 2026

A Common Mistake

A frequent first-week belief is that the .java file is what the computer executes, so editing the source and re-running should be enough. The JVM runs .class bytecode, not source. When a change does not seem to take effect, the usual cause is a skipped compile step: the old .class is still on disk. Recompile, then run. (Source: BJP (Reges and Stepp), Ch 1; JLS 25, §12.1, Java Virtual Machine Startup.)

Go Deeper (optional)

For the curious: bytecode is not machine code for any real processor. It is an instruction set for an abstract machine, and the JVM translates it to the host processor as the program runs (just-in-time compilation). That extra layer is what allows one .class file to run unchanged on very different hardware. None of this is needed to write programs, but it explains why Java describes itself as “write once, run anywhere.”

Check Yourself

Close the notes and answer each one from memory, then reveal it. Pulling an idea back from memory is one of the strongest ways to make it stick.