Where does single-file source execution sit in Java's evolution toward lower-ceremony programs, and how have JEP 458 and implicit main methods extended it?

## The throughline: "lower the ceremony" Classic Java demands a lot for a 'hello world': a `public class`, a `public static void main(String[] args)`, a `javac` compile, and a `java` run. Java has spent several releases dismantling that for **beginners and scripting**, without changing the language for everyone else. Single-file source execution is one milestone in that arc; understanding where it sits is a principal-level framing question. ### Milestone 1 — JShell (Java 9) An interactive **REPL** (Read-Eval-Print Loop) for evaluating fragments with no class/main. Removes ceremony for *exploration*. ### Milestone 2 — Single-file source execution (JEP 330, Java 11) Run **one** complete `.java` file directly: `java Hello.java` compiles in memory and runs `main`. Removes the explicit compile step for a single-file *program*, and (via shebang + `--source`) enables Java as a Unix script. Its key limit: **one source file, no separate compilation, no artifact**. ### Milestone 3 — JEP 458: Launch Multi-File Source-Code Programs (finalized Java 22) The obvious next gap was "my script grew past one file." JEP 458 extends the launcher so that, when you `java App.java`, it will also **compile the other source files App references from the same source tree, in memory, on demand**. This effectively removes the single-file restriction for source-mode runs while staying build-tool-free: a small project can run straight from source. It bridges single-file mode and full build tooling. ### Milestone 4 — Implicit classes & instance main methods (JEP 445 preview → 463 → 477 → **JEP 512 final in Java 25**) This line attacks the *boilerplate inside* the file. Progressively, Java allowed: - An **instance `main`** (not `static`) and a **no-args `main()`** form. - An **implicitly declared (unnamed) class**: you can write just the methods/`main` with no surrounding `class Foo { }`. - Auto-available console I/O helpers (e.g. `IO.println` / simplified `println`) so beginners don't wrestle with `System.out` or imports on day one. Result — a complete runnable file can be as small as: ```java void main() { System.out.println("Hello"); } ``` run with `java Hello.java`. No `class`, no `static`, no `String[] args`. ## How they compose These are **orthogonal and stack**: implicit-class/instance-main reduces *in-file* ceremony; single-file/JEP 458 source launch reduces *compile/run* ceremony; together they make Java approachable for first programs and scripts. Crucially, all are **source-compatible escalators** — a beginner's `void main()` file is still ordinary Java that can later grow an explicit class, move into packages, and be built by Maven/Gradle. Nothing about these features changes the production model; they're an **on-ramp**, and the language designers were explicit that real applications still use build tools, modules, and packaging. ## Why a principal cares - **Onboarding & education strategy:** these features shorten time-to-first-program and reduce the conceptual load (no premature `static`, classes, or arrays), which matters for hiring pipelines and teaching. - **Scripting credibility:** with JEP 458 + shebang, Java competes with Python/Bash for ops glue where teams value Java's type system and libraries — while you must still decide *when* a script should become a built, tested, versioned artifact. - **Governance:** knowing these are deliberately *non-build-tool* on-ramps helps set policy (e.g. "prototypes/scripts may use source mode; anything shipped must be a Maven/Gradle module with tests"). ## Boundaries that remain Source mode (even multi-file) still produces **no persistent artifact**, recompiles each run, and isn't a substitute for dependency management, testing infrastructure, reproducible builds, or packaging. The art is choosing the right rung of the ceremony ladder for the task.