Introduction to Java

People use the word "Java" for three different things: a language, a compiler, and a virtual machine. Most of the confusion beginners have about Java comes from not noticing that. This post separates them, then explains why the arrangement was worth building and where it leaves Java in 2026.

Three things, one name

When you ran javac Hello.java and then java Hello in the previous post, you used all three:

The thing	What it is	You met it as
The language	The rules for what counts as valid Java — classes, types, semicolons. This is what the other 27 posts teach.	the text in `Hello.java`
The compiler	Reads that text, checks it, and emits bytecode.	`javac`
The JVM	A program that executes bytecode. It does not know or care that Java exists.	`java`

That last row is the one worth dwelling on.

Bytecode and the JVM

Most compiled languages turn your source into machine code for one specific processor and operating system. Build on a Mac, and the result does not run on Windows.

Java compiles to bytecode instead — instructions for an imaginary computer. The JVM is a real program that pretends to be that imaginary computer, and there is a JVM for every platform anyone cares about. So the .class file you built on your laptop runs unchanged on a Linux server.

That is what "write once, run anywhere" means, and it is not a marketing slogan you can ignore — it is why Java runs on banking mainframes, Android phones and AWS Lambda without anyone maintaining three versions of the code.

The JVM does more than translate, though. Three things it gives you for free:

Garbage collection. You allocate objects; you never free them. The JVM notices when nothing refers to an object any more and reclaims it. Entire categories of bug — use-after-free, double-free, most memory leaks — simply do not happen.
JIT compilation. "Interpreted languages are slow" is the old complaint, and the JVM answered it. It watches which code runs often and compiles those parts to real machine code while the program is running, using facts it could not know ahead of time. Long-running Java gets faster after it starts, and lands close to C for most work.
Memory safety. Read past the end of an array and you get an ArrayIndexOutOfBoundsException, not silent corruption.

What the language is like

Four properties define the day-to-day feel of writing Java.

Statically typed. Every variable has a type fixed at compile time, and the compiler rejects the program if the types do not line up. This is the trade Java makes: more typing up front, in exchange for a large class of mistakes being caught before the code ever runs.

int count = 10;
count = "ten";   // does not compile: incompatible types: String cannot be converted to int

In a dynamically typed language that assignment is legal and fails later — possibly in production, possibly at 3am. Here it fails in your editor.

Object-oriented. Code lives in classes. Even the smallest program has one, which is why Hello needed a class to hold a single line. OOP covers what that buys you.

Verbose, on purpose. Java says things out loud that other languages infer. This is a real cost when writing and a real benefit when reading — and you read code far more than you write it. Recent versions have trimmed the worst of it: var, records, and text blocks all remove ceremony without removing the type checking.

Backwards compatible to a fault. Code compiled for Java 8 in 2014 still runs on a Java 25 JVM. This is unglamorous and it is the single biggest reason large companies bet on Java — upgrading the runtime does not mean rewriting the application.

Where Java is actually used

Java is not a legacy language, but it is also not used for everything. It dominates in a few specific places:

Server-side business systems. The core of it — banks, insurers, airlines, retailers, payment processors. Spring Boot is the framework most of that is written in.
Android. The platform is Java-based; Kotlin is now preferred for new code, but Kotlin runs on the JVM and interoperates with Java directly.
Big data infrastructure. Hadoop, Spark, Kafka, Elasticsearch and Cassandra are all JVM software.
Anything that has to run for months. The JIT and the mature garbage collectors make Java strong exactly where a process stays up under load.

It is a poor fit for quick scripts, and it is not what you would pick for a small command-line tool. That is fine — no language wins everywhere.

Versions, and why people are on old ones

Java ships every six months, and every few years one release is designated LTS — Long-Term Support, patched for years rather than months. The get-started post has the full table of what each LTS added; the short version is 8, 11, 17, 21 and 25.

Companies run LTS releases and skip everything between, which is why you will meet Java 8 and Java 17 codebases far more often than Java 22.

Java 8 is the line that matters. It introduced lambdas and streams, and code written before and after it genuinely reads like two different languages:

List<String> names = List.of("ana", "bo", "cy");

// Before Java 8
List<String> upperOld = new ArrayList<>();
for (String name : names) {
    upperOld.add(name.toUpperCase());
}

// Java 8 onwards — same result
List<String> upperNew = names.stream()
        .map(String::toUpperCase)
        .toList();

Both are correct and you will meet both. Knowing that the second is available is what stops you writing 2011 Java in 2026, and it is why this track spends Lambda Expressions on the modern style rather than treating it as an advanced extra.

One consequence worth knowing now: a great deal of the Java advice you find by searching predates Java 8, and it is not marked as such. When an answer tells you to use Date, Vector, or a raw List without a type parameter, it is old. This track says so each time it comes up.

That is the context. From here the track is hands-on, starting with the smallest unit of a Java program: variables — what they are, the three kinds, and where each one is visible.