What Changed Between Java 8 and Java 21?

The headline changes fall into three groups. The first wave gave the language lambdas, method references, the Stream API, the modern date and time library and Optional — the single largest jump in how ordinary Java is written. The second wave modernised the platform: the module system, local variable type inference with var, switch expressions, text blocks, records, pattern matching for instanceof and sealed classes. The third wave completed that work with pattern matching for switch and virtual threads, which changed how concurrent Java is written. The sample above is written with the features every recent JDK supports, so you can run it as it is. The sample above is written with the features every recent JDK supports, so you can run it as it is.

import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

public class Main {
    public static void main(String[] args) {
        // lambdas and streams.
        var names = List.of("Ada", "Grace", "Alan");
        String upper = names.stream()
                .map(String::toUpperCase)
                .collect(Collectors.joining(", "));
        System.out.println("upper    : " + upper);

        // var for local type inference.
        var counts = names.stream()
                .collect(Collectors.groupingBy(String::length, Collectors.counting()));
        System.out.println("by length: " + counts);

        // switch expressions with multiple labels per case.
        int day = 3;
        String kind = switch (day) {
            case 1, 7 -> "weekend";
            case 2, 3, 4, 5, 6 -> "weekday";
            default -> "unknown";
        };
        System.out.println("day " + day + " : " + kind);

        // Optional, to keep the null check out of the caller.
        java.util.Optional<String> maybe = java.util.Optional.of("present");
        System.out.println("optional : " + maybe.orElse("absent"));
    }
}

The output shows one representative feature from each era working together in a single class.

If you are asked what you would use daily, the honest answer is: lambdas and streams, var, switch expressions, records, text blocks, and pattern matching for instanceof. The others — modules, sealed types, virtual threads — matter for particular kinds of work and are worth knowing about rather than using everywhere.

Two things that are easy to get wrong. var is for local variables only, and it infers the type rather than making it dynamic — the variable is still statically typed. And switch expressions differ from switch statements in that they are exhaustive: over an enum they must cover every constant, and adding a constant to the enum turns a missing branch into a compile error.

The features you are most likely to use arrived in waves. First lambdas, method references, the Stream API and Optional. Then the var keyword and the new collection factory methods. Then switch expressions and text blocks. Then records, pattern matching for instanceof and sealed classes. And most recently pattern matching for switch, virtual threads and the sequenced collections.

To find out what a running JVM supports, you ask it. The system properties give you the version, and Runtime.version() gives you a structured answer with the feature, interim, update and patch numbers separated. That is more useful than parsing a version string, because you can compare the feature number directly.

public class Main {
    public static void main(String[] args) {
        System.out.println("java.version : " + System.getProperty("java.version"));
        System.out.println("spec version : " + System.getProperty("java.specification.version"));
        System.out.println("vm name      : " + System.getProperty("java.vm.name"));
        System.out.println("runtime      : " + Runtime.version());
        System.out.println("feature      : " + Runtime.version().feature());
        System.out.println("is recent Java  : " + (Runtime.version().feature() >= 21));
        System.out.println("is Java 17+  : " + (Runtime.version().feature() >= 17));
    }
}

The output shows the version in three different forms. The java.version property is the marketing string, the specification version is the JSR number for that release, and Runtime.version() breaks it into its parts. The two comparisons at the end are what you would write if your code needs to behave differently on an older runtime.

For finding out what a API supports rather than what the runtime is, the class file version is the thing to check. ClassFile information is embedded in every class, and a mismatch between the class-file version and the runtime produces the UnsupportedClassVersionError. Building with javac --release N guarantees that the class files and the APIs both match the target version, rather than compiling against a newer JDK and hoping the deployment host is up to date.