Compile and run with java and javac

Follow a source file through compilation, execution, a stale class file, and a repaired compiler error.

This is a fresh Java VM session. All starting files are supplied here; no notebook or earlier lesson is required. Work through the experiments, predict each result, and inspect what actually changed. Resetting or leaving discards guest files.

From a cell to a source file

The notebook supplies surrounding Java structure for a short expression. A command-line application needs a complete entry point. This lesson provides Hello.java; you do not need to remember a template or create it yourself.

public class Hello {
    public static void main(String[] args) {
        System.out.println("Welcome, hikers!");
    }
}

Hello is the class name. Because it is public, its source filename is Hello.java. Braces group the class and method bodies. The conventional main method is where the launcher starts. String[] args receives command-line arguments; we will use it in the JBang lesson. For now, the only action is printing a quoted message, terminated by a semicolon.

Two commands, two jobs

flowchart LR
  Source[Hello.java: source text] -->|javac Hello.java| Bytecode[Hello.class: bytecode]
  Bytecode -->|java Hello| JVM[JVM loads and executes the class]
  JVM --> Output[Printed message]

javac Hello.java reads source and writes a class file. This guest uses an interpreted Java 27 build, so no interpreter option is needed. On a normal computer, javac Hello.java is the same usual command. Successful compilation usually prints nothing. Silence is not proof of a missing result: inspect Hello.class. Bytecode is a binary representation intended for the JVM, not a readable copy of the source.

java Hello names the class to launch, without .class. Run it from the directory containing the class. In this lab the default class path includes the current directory. The JVM loads compiled code; it does not inspect Hello.java to see whether you edited it.

Source and bytecode can disagree

Changing a message in the source does not update an existing class file. Predict the output before the second run: until recompilation, the old message remains. This is a useful debugging question whenever someone says a change had no effect: which artifact did the command actually execute?

The sed command used here replaces a specific string. It is a small reproducible edit, not a Java compiler. Read the source after editing, run the old class, then compile and run again. Keep these observations separate so the before/after relationship is visible.

A compiler error is a source location

The supplied Broken.java omits a semicolon. Read the filename and line in the first diagnostic, then inspect the nearby code. A caret marks where the parser noticed a problem; the original mistake may be just before it. Do not fix unrelated code based on the number of diagnostics. One missing punctuation mark can cause several messages.

A failed compilation does not establish a runnable program. In this fixture there is no older Broken.class, so a class should appear only after the repair. The final check needs both a generated class and the printed Trip ready! message.

The environment you are observing

The guest includes 64-bit source-built OpenJDK 27 Zero (interpreter only). Its JVM runs inside the browser emulator. Compilation takes much longer here than in a normal environment; wait for the shell prompt to return before entering the next command. Read the actual java --version and javac --version output rather than copying a version from another course. Compiler and runtime are different tools from the same installation here. This lesson uses conventional syntax available well before Java 27.

First runs can take time. Wait for the shell prompt before sending another command or checking a step. Reset lab starts from the original source files. No local JDK installation or account is required.

Predict before you run

For every experiment, say which file is read, which file may be written, and whether you expect printed output. At the end you should be able to explain why source editing, successful compilation, and execution are three distinct events.

Reference: Java launcher and javac.

Source

A .java file is text that expresses the program.

Bytecode

A .class file holds compiled instructions for the JVM.

JVM

The runtime loads and executes bytecode; it does not automatically rebuild an edited source file.

Identify the compiler and runtime

Run both version commands. Find the feature version and vendor in the runtime output, then compare the compiler version. Both should report feature version 27; longer vendor and build suffixes need not look identical.

java --version

javac --version

Java 27 and javac 27

Read the supplied source

You are already in ~/java-lab. First run cat Hello.java to read the supplied source. Locate the class name, main method, quoted message, braces, and semicolon. Then run ls Hello* to list the files whose names begin with Hello. You should see only Hello.java: the compiled Hello.class does not exist yet.

cat Hello.java

ls Hello*

Hello.java; no class file yet

Compile source into bytecode

Run javac Hello.java to compile the source. Compilation takes much longer in this browser VM than on a normal computer. Wait for the shell prompt to return; successful compilation normally prints nothing. Then run ls Hello* again. Compare it with the previous listing: Hello.class should now appear alongside Hello.java. Do not run the program yet.

javac Hello.java

ls Hello*

Hello.class exists

Launch the compiled class

Run java Hello. Predict which message comes from main. The command selects the class name, so do not append .java or .class. Java source-file launch is a separate workflow introduced later.

java Hello

Welcome, hikers!

Edit source and observe stale bytecode

Use sed -i 's/Welcome/Ready/' Hello.java to replace Welcome with Ready in the source file. Then read the source with cat Hello.java and run the already compiled class with java Hello. The source now says Ready but the output still says Welcome. Explain which artifact is stale before continuing.

sed -i 's/Welcome/Ready/' Hello.java

cat Hello.java

java Hello

Source: Ready; output: Welcome

Recompile and observe the new output

Compile the changed source with javac Hello.java, then run java Hello again. The class file now carries the changed string. This is the missing step when a source edit has no effect on an existing class.

javac Hello.java

java Hello

Ready, hikers!

Read a deliberate compiler error

Read Broken.java with cat Broken.java, then compile it with javac Broken.java. A failed command is expected here. Locate the first diagnostic and the missing semicolon after println. Check that compilation did not create Broken.class.

cat Broken.java

javac Broken.java

error: semicolon expected

Repair, compile, and run

Use sed -i 's/println("Trip ready!")/println("Trip ready!");/' Broken.java to add the missing semicolon. Then read the repaired source with cat Broken.java, compile with javac Broken.java, and launch with java Broken. Confirm both the binary class and its output. A text edit alone cannot satisfy the repaired-program check.

sed -i 's/println("Trip ready!")/println("Trip ready!");/' Broken.java

cat Broken.java

javac Broken.java

java Broken

Trip ready!

You completed the tooling workflow using real commands and files. Explain each result before moving on; tool output is evidence, not a substitute for the Java rule behind it.

Enable JavaScript to run the live terminal and track your progress.