Session 1 — Programs, the JVM, and your first main

You will learn what happens between saving a .java file and seeing output in a terminal: source code, the compiler, bytecode, and the Java Virtual Machine (JVM) as the runtime that executes portable instructions. You will write a minimal main method, call the standard library to print text, and recognise the class/file naming rule that trips many beginners.

Plan: runtime story → smallest program → compile/run mental model → bridge → practice → reveal.

Time: about 80 minutes with typing and one local compile cycle.

1. What “running Java” actually means

Java source lives in files ending in .java. Those files are text for humans; the machine does not execute them directly. A compiler (the javac tool in a JDK) reads your source and emits bytecode files ending in .class. Bytecode is a compact instruction stream aimed not at your physical CPU chips alone, but at the Java Virtual Machine (JVM)—a program that interprets or compiles those instructions at runtime.

Why bother with two steps? The same bytecode can run anywhere a compatible JVM exists, which is how “write once, run many places” became Java’s headline promise. Your responsibility in a first course is narrower: keep the picture straight—you edit .java, the toolchain produces .class, the JVM runs the entry point you declare.

---

2. The smallest executable unit is a class

Java organises code into classes. Even your first program is a class with a name you choose (conventionally starting with an uppercase letter, e.g. Greeter). Inside the class you place methods—named blocks of code. The JVM looks for a very specific method signature to start work:

public static void main(String[] args) {
    // program starts here
}

Reading the signature aloud:

• public — the method can be called from outside the class by the runtime machinery.
• static — the method belongs to the class itself, not to an individual object instance you will construct later with new.
• void — this method does not return a value to its caller.
• main — the fixed name the JVM searches for.
• String[] args — optional command-line arguments arrive as an array of strings.

If any piece of that signature is wrong (for example Main capitalised, or void missing), the JVM will not treat the file as an entry point even if everything else compiles.

---

3. Printing to the console

The standard library exposes a prebuilt object System.out whose println method writes a line of text and moves the cursor to the next line:

System.out.println("Hello from Java");

println accepts many types—it will convert numbers and other values to a human-readable string using default rules. Later sessions discuss formatting; for now, rely on println for honest debugging prints.

---

4. File name vs public class name

If a top-level class is declared public, its source file name must match exactly (including case) and end with .java. A public class Greeter must live in Greeter.java. The compiler enforces this because the JVM loads classes by name.

You may legally place non-public helper classes in the same file, but beginners should keep one public class per file until packaging topics arrive.

---

5. Packages (light touch)

A line such as package com.example.lab; at the very top declares a namespace so large projects avoid name clashes. The compiler expects folder structure to mirror the package (com/example/lab/). If you omit package, you are in the default package—fine for tiny experiments, discouraged for shared libraries.

This course keeps most snippets in the default package so you can paste them into a single file quickly.

---

6. Errors you should welcome early

• “cannot find symbol” — typo in a class or method name, or missing import (not needed for java.lang types like String or System).
• “class … is public, should be declared in a file named …” — rename the file or the class so they match.
• main not found — signature mismatch; compare letter-for-letter with the template above.

Reading the first compiler error carefully saves more time than randomly rewriting working lines.

---

7. Mental checklist before every run

1. Saved the file?
2. public class name matches file name?
3. public static void main(String[] args) present?
4. Braces balanced around class and method bodies?

If all four are true, you are ready to compile and execute.

Example A — Greeter.java end-to-end

public class Greeter {
    public static void main(String[] args) {
        System.out.println("Portable bytecode says hello");
        if (args.length > 0) {
            System.out.println("First argument: " + args[0]);
        } else {
            System.out.println("No arguments passed");
        }
    }
}

Compile: javac Greeter.java produces Greeter.class.

Run without args: java Greeter prints the greeting then the “No arguments” branch.

Run with args: java Greeter Alice prints the greeting then First argument: Alice.

Notice args.length—arrays know their length; there is no separate counter variable to maintain for command-line input.

---

Example B — default package vs named package (conceptual)

If you later write:

package workshop.intro;

public class Greeter {
    public static void main(String[] args) {
        System.out.println("Namespaced greeter");
    }
}

You must place the file at workshop/intro/Greeter.java relative to your source root and run with the fully qualified name (java workshop.intro.Greeter) or configure your build tool’s classpath. Until you are comfortable with paths, stay in the default package for scratch files.

---

Example C — brace style is a readability choice

Java ignores extra whitespace, but humans do not. Pick one brace style and stay consistent:

public class Counter {
    public static void main(String[] args) {
        int n = 0;
        n = n + 1;
        System.out.println(n);
    }
}

The compiler only cares that { and } enclose the correct scopes. Indentation is for you and your collaborators.

JVM story ↔ how you will practise later

1. Python interpreters often read source directly; Java’s two-step compile-then-run explains why you always see .class artefacts in build folders.

2. C programs compile to machine code for one architecture; Java targets an abstract machine first—trade-off: startup and packaging steps, reward: portability.

3. IDE buttons (Run) wrap javac + java; when something breaks in coursework, drop to the terminal once so you recognise the underlying commands.

4. Logging frameworks (later in industry) still bottom out on PrintStream-style output—the println habit is honest debugging forever.

When you can narrate those four comparisons aloud, the JVM stop feeling like magic smoke.