I see this happen constantly with new developers: they treat the java command like a Python or Ruby interpreter. They write a file, type java MyProgram.java, and when it doesn't behave exactly how they expect—or when they see a Could not find or load main class error—they assume their code is broken. In reality, their code is fine; their mental model of how Java actually reaches the CPU is what's broken.

The Myth: "java" is a one-step command

If you've played around with modern Java (version 11+), you might have noticed you can actually run a single file using java MyFile.java. This creates the illusion that Java is an interpreted language. But here is where the trap lies: doing this doesn't produce a reusable artifact. If you try to run that same program again, or try to reference it from another class, you'll realize you have nothing to show for it on your disk except the original source code.

In a professional environment, we almost never "run the source." We compile it into bytecode. If you skip the compilation step and try to run a class that hasn't been compiled yet by calling java MyProgram (without the .java extension), the Java Virtual Machine (JVM) will look for a MyProgram.class file, fail to find it, and crash with a cryptic error. It's not looking for your text file; it's looking for the machine-readable version.

The Reality: The two-step dance of javac and java

To understand this, let's use a real scenario. Imagine we're building a TemperatureConverter. You've written your logic to switch between Celsius and Fahrenheit in a file named TemperatureConverter.java.

The first tool you need is javac. This is the Java Compiler. Its only job is to translate your human-readable code into "bytecode"—a highly optimized set of instructions that the JVM understands. When you run this command:

javac TemperatureConverter.java

Nothing seems to happen in the terminal. That's actually a good thing in the world of C-style compilers; no news is good news. But if you look at your folder, a new file has appeared: TemperatureConverter.class. This is the "compiled" version. This is what actually gets shipped to production servers, not your .java files.

Now that we have the bytecode, we use the java command (the launcher) to start the JVM and execute that class. But here is the part that trips people up: you do not include the file extension here.

java TemperatureConverter

I want you to notice the difference. javac takes a file (hence the .java). java takes a class name. If you type java TemperatureConverter.class, the JVM will look for a class literally named "class" inside a package named "TemperatureConverter", and it will fail miserably.

I've spent hours of my career debugging "Class Not Found" errors only to realize I had a typo in the class name or was accidentally including the extension in the run command. It's a rite of passage. Just remember: javac creates the artifact; java breathes life into it.

📋 Practical Task

Debug the TemperatureConverter Execution Workflow

You have been handed a file named TemperatureConverter.java. Your goal is to get the program running on your machine, but you've encountered a series of errors. Follow these steps to fix the workflow:

The Setup:
Create a file named TemperatureConverter.java with the following content:

public class TemperatureConverter {
    public static void main(String[] args) {
        double celsius = 25.0;
        double fahrenheit = (celsius * 9/5) + 32;
        System.out.println(celsius + "C is " + fahrenheit + "F");
    }
}

The Challenge:
1. Try to run the program using java TemperatureConverter immediately. Observe the ClassNotFoundException or Could not find or load main class error. Explain to yourself why this happened based on the lesson.
2. Use the correct compiler command to generate the bytecode.
3. Run the program using the correct launcher command (remember: no file extensions!).
4. Verify that TemperatureConverter.class exists in your directory and delete the .java file. Try running the program again using the java command. Notice how the program still runs even though the source code is gone—this is the power of the compiled bytecode.