The Java Knowledge Ocean: Java: Usage & Interview Tips

JDK 8 → 17 → 21 → 25: The Key Leaps Across Four LTS Generations, Explained at Once

Dylan Smith — Mon, 10 Aug 2026 12:15:25 GMT

Preface

This article is a technical summary from my own experience upgrading from JDK 8 all the way to JDK 25 in production. It covers four LTS releases — JDK 8 (2014), JDK 17 (2021), JDK 21 (2023), and JDK 25 (2025) — spanning 11 years of Java evolution.

I’m not going to dump a feature list and call it a day. For each version I’ll include real code examples, analysis of JVM internals, and GC tuning parameters. If you’re considering a version upgrade, or you want to understand what actually changed at a fundamental level over this decade of the Java platform, this article should help.

1. Version Positioning and Release Strategy

First, let’s make the positioning of the four versions clear:

The change in release cadence is the key to understanding the Java ecosystem:

Before JDK 8: major versions were 2–3 years apart, features piled up, and delays were the norm (JDK 9 slipped by three years)
After JDK 9: switched to the six-month train model, with releases every March and September
LTS cadence: originally one LTS every three years (8 → 11 → 17); starting with JDK 17 it became every two years (17 → 21 → 25)

This strategy shift directly affected our technology choices. Many teams stayed on JDK 8 for nearly a decade, mainly because there was no LTS worth the risk of upgrading between JDK 9 and JDK 16. JDK 17 was the first version that really made everyone think “it’s time to upgrade.”

A word on licensing: after JDK 8u211, commercial use of Oracle JDK requires a paid license. Starting with JDK 17, Oracle restored the NFTC (No-Fee Terms and Conditions) license, which allows free commercial use. That said, many companies have already moved to distributions like Adoptium (Eclipse Temurin), Amazon Corretto, and Azul Zulu, which are free at every version.

2. Language Feature Evolution

2.1 JDK 8: The Lambda & Stream Functional Revolution

JDK 8 was the most significant language-level change in Java’s history. It introduced four core features at once — Lambda, Stream, Optional, and the new date-time API — and directly changed Java’s programming paradigm.

Lambda expressions and functional interfaces

Before JDK 8, writing a sort looked like this:

// JDK 7 style
List names = Arrays.asList(”Charlie”, “Alice”, “Bob”);
Collections.sort(names, new Comparator() {
    @Override
    public int compare(String a, String b) {
        return a.compareTo(b);
    }
});

After JDK 8:

// JDK 8 style
List names = Arrays.asList(”Charlie”, “Alice”, “Bob”);
names.sort(String::compareTo);

The underlying implementation of Lambda is worth understanding: it is not syntactic sugar for anonymous inner classes. The compiler uses the invokedynamic instruction and generates the implementation class at runtime through LambdaMetafactory, avoiding the problem of anonymous inner classes generating a large number of .class files at compile time. You can see the difference with javap -c -p:

// Anonymous inner class: generates MyClass$1.class
// Lambda: compiles to an invokedynamic instruction
0: invokedynamic #2, 0  // InvokeDynamic #0:compare:()Ljava/util/Comparator;

Stream API

The core design of Stream is lazy evaluation. Intermediate operations (filter, map, flatMap) don’t execute immediately; only a terminal operation (collect, forEach, reduce) triggers the entire pipeline to be processed in one pass:

// Real-world scenario: extract emails of high-value customers from an order list
List vipEmails = orders.stream()
    .filter(o -> o.getAmount().compareTo(new BigDecimal(”10000”)) > 0)
    .map(Order::getCustomer)
    .filter(c -> c.getVipLevel() >= 3)
    .map(Customer::getEmail)
    .distinct()
    .sorted()
    .collect(Collectors.toList());

My advice on parallel streams: use them very rarely in web applications. Under the hood, parallel streams use ForkJoinPool.commonPool(), a globally shared thread pool. If you process a long-running operation with a parallel stream inside one HTTP request, it affects the parallel streams running in other requests. We once hit production timeouts because of exactly this.

The diagram above shows the complete Stream pipeline — from the data source to the intermediate operations (lazy) to the terminal operation (triggering execution) — along with the Fork-Join divide-and-conquer model of parallel streams.

Optional

// Chain handling of values that may be null
String cityName = Optional.ofNullable(user)
    .map(User::getAddress)
    .map(Address::getCity)
    .map(City::getName)
    .orElse(”Unknown”);

The java.time API

It finally replaced the disastrous java.util.Date and Calendar:

// JDK 8 date handling
LocalDateTime now = LocalDateTime.now();
LocalDateTime meetingTime = now.plusHours(2).withMinute(0).withSecond(0);
Duration duration = Duration.between(now, meetingTime);
System.out.println(”Minutes until the meeting: “ + duration.toMinutes());

// Time zone handling
ZonedDateTime shanghaiTime = ZonedDateTime.now(ZoneId.of(”Asia/Shanghai”));
ZonedDateTime newYorkTime = shanghaiTime.withZoneSameInstant(ZoneId.of(”America/New_York”));

2.2 The Key Transition Features of JDK 9–16

Many people skip this stretch, but in reality every transition feature from JDK 9–16 became standard in later LTS releases. If you don’t understand how they evolved, those features will feel like they “appeared out of nowhere” when you use JDK 17/21.

JDK 9: The module system (Project Jigsaw)

// module-info.java
module com.myapp.core {
    requires java.sql;
    requires java.logging;
    exports com.myapp.core.api;
    opens com.myapp.core.model to com.fasterxml.jackson.databind;
}

JDK 9 also introduced collection factory methods, JShell, and private interface methods:

// Immutable collections (JDK 9)
List list = List.of(”a”, “b”, “c”);
Map map = Map.of(”key1”, 1, “key2”, 2);

// Private interface methods
public interface Validator {
    default boolean isValid(String input) {
        return !isEmpty(input) && checkFormat(input);
    }
    private boolean isEmpty(String input) {
        return input == null || input.isBlank();
    }
    private boolean checkFormat(String input) {
        return input.matches(”[a-zA-Z]+”);
    }
}

JDK 10: Local variable type inference (var)

// var is not dynamic typing; it is compile-time type inference
var userList = new ArrayList();        // inferred as ArrayList
var stream = userList.stream();              // inferred as Stream
var result = Map.of(”key”, List.of(1, 2));   // inferred as Map>

JDK 11: String enhancements, HttpClient standardized

// New String methods
“  hello  “.strip();           // “hello” (Unicode-aware trim)
“hello”.repeat(3);             // “hellohellohello”
“line1\nline2\n”.lines()       // Stream
    .forEach(System.out::println);
“”.isBlank();                  // true

// Single-file execution
// $ java HelloWorld.java    (no need to run javac first)

JDK 14: Records (preview), instanceof pattern matching (preview)

// Record: immutable data carrier
record Point(int x, int y) {}

// Helpful NPE messages (final in JDK 14)
// Before: NullPointerException
// After: Cannot invoke “String.length()” because “a.b.name” is null

JDK 15: Text Blocks

String json = “”“
        {
            “name”: “Zhang San”,
            “age”: 28,
            “roles”: [”admin”, “user”]
        }
        “”“;

2.3 JDK 17: The Maturation of Language Features

JDK 17 finalized all the features previewed between JDK 14 and 16, forming a complete “modern Java” feature set.

Sealed Classes (JEP 409)

Sealed classes restrict the set of permitted subclasses. Combined with pattern matching, the compiler can perform exhaustive checks:

The diagram above shows the inheritance constraints of Sealed Classes — a sealed interface only allows the specified subclasses to implement it, final subclasses can no longer be inherited, and non-sealed subclasses remain open for extension.

// Define a sealed shape hierarchy
public sealed interface Shape permits Circle, Rectangle, Triangle {
    double area();
}

public record Circle(double radius) implements Shape {
    public double area() { return Math.PI * radius * radius; }
}

public record Rectangle(double width, double height) implements Shape {
    public double area() { return width * height; }
}

public record Triangle(double base, double height) implements Shape {
    public double area() { return 0.5 * base * height; }
}

Pattern Matching for instanceof (JEP 394)

// JDK 16 and earlier style
if (obj instanceof String) {
    String s = (String) obj;
    System.out.println(s.length());
}

// JDK 17 style
if (obj instanceof String s) {
    System.out.println(s.length());
}

// Combined with sealed classes
public static String describe(Shape shape) {
    if (shape instanceof Circle c) {
        return “Circle with radius “ + c.radius();
    } else if (shape instanceof Rectangle r) {
        return “Rectangle “ + r.width() + “x” + r.height();
    } else if (shape instanceof Triangle t) {
        return “Triangle with base “ + t.base();
    }
    // Sealed classes guarantee this line is unreachable, but the compiler
    // does not perform exhaustiveness checks on if-else chains.
    // You need switch pattern matching (JDK 21) for compile-time exhaustiveness.
    throw new IllegalStateException();
}

Other notable JDK 17 changes:

Removed the Graal interfaces for AOT and JIT compilers (JEP 410) — this means if you want to use GraalVM, you need to install it separately
Strong encapsulation of JDK internal APIs (JEP 403) — --illegal-access=permit no longer takes effect
Removed RMI Activation (JEP 407)
Restored always-strict floating-point semantics (JEP 306)

2.4 The JDK 18–20 Transition

These three non-LTS releases paved the way for the two killer features of JDK 21:

JDK 18: default charset changed to UTF-8 (JEP 400), Simple Web Server (JEP 408)
JDK 19: Virtual Threads first preview (JEP 425), Structured Concurrency incubated (JEP 428)
JDK 20: Scoped Values incubated (JEP 429), Record Patterns second preview (JEP 432)

2.5 JDK 21: The Concurrency Model Revolution

JDK 21 is the most significant change to the Java platform since JDK 8. The GA release of Virtual Threads fundamentally changed Java’s concurrency programming model.

Virtual Threads (JEP 444)

Calling a Virtual Thread a “lightweight thread” doesn’t do it justice. Its essence is turning threads from an operating system resource into a JVM-managed resource.

Problems with traditional Platform Threads:

Each thread occupies about 1 MB of stack memory (configurable; default -Xss1m)
Thread creation and destruction involve system calls (pthread_create/pthread_exit)
Context switching is expensive (kernel-mode switching)
The number of threads a single JVM process can create is usually in the thousands to tens of thousands

How Virtual Threads are implemented:

Managed by the JVM, not directly mapped to OS threads
Use Continuations to save and restore execution state
On blocking operations (I/O, sleep, locks, etc.), automatically unmount from the carrier thread
When the block clears, scheduled to continue on any available carrier thread
Stack space grows on demand, starting at only a few hundred bytes

// Three ways to create a Virtual Thread
// Way 1: Thread.startVirtualThread
Thread vt = Thread.startVirtualThread(() -> {
    System.out.println(”Running in virtual thread: “ + Thread.currentThread());
});

// Way 2: Thread.ofVirtual()
Thread vt2 = Thread.ofVirtual()
    .name(”my-vt-”, 0)
    .start(() -> doWork());

// Way 3: ExecutorService (recommended for production)
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    // One virtual thread per task; no thread pool needed
    IntStream.range(0, 100_000).forEach(i -> {
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1));
            return i;
        });
    });
}

Performance comparison: 100,000 concurrent tasks

public class VirtualThreadBenchmark {

static final int TASK_COUNT = 100_000;
    public static void main(String[] args) throws Exception {
        // Platform Threads (pool limited to 200 threads)
        long startPlatform = System.nanoTime();
        try (var executor = Executors.newFixedThreadPool(200)) {
            var futures = IntStream.range(0, TASK_COUNT)
                .mapToObj(i -> executor.submit(() -> {
                    Thread.sleep(Duration.ofMillis(100));
                    return i;
                }))
                .toList();
            for (var f : futures) f.get();
        }
        long platformTime = System.nanoTime() - startPlatform;
        // Virtual Threads
        long startVirtual = System.nanoTime();
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            var futures = IntStream.range(0, TASK_COUNT)
                .mapToObj(i -> executor.submit(() -> {
                    Thread.sleep(Duration.ofMillis(100));
                    return i;
                }))
                .toList();
            for (var f : futures) f.get();
        }
        long virtualTime = System.nanoTime() - startVirtual;
        System.out.printf(”Platform Threads (200 pool): %.2f seconds%n”,
            platformTime / 1_000_000_000.0);
        System.out.printf(”Virtual Threads:             %.2f seconds%n”,
            virtualTime / 1_000_000_000.0);
    }
}
// Typical output:
// Platform Threads (200 pool): 50.12 seconds
// Virtual Threads:              0.15 seconds

The core reason for this gap: 200 Platform Threads executing 100,000 blocking tasks of 100 ms each takes at least 100000 / 200 * 0.1 = 50 seconds. Virtual Threads, on the other hand, can create 100,000 threads at once; all tasks start sleeping at almost the same time and finish almost simultaneously 0.1 seconds later.

The diagram above directly compares the core differences between platform threads and virtual threads — platform threads are bound to OS threads (heavyweight, 1 MB stack), virtual threads are scheduled by the JVM (lightweight, KB-level), and on I/O blocking they automatically unmount from the carrier thread.

Pitfalls of Virtual Threads

When using Virtual Threads in production, watch out for the following:

I/O inside synchronized blocks causes pinning: a Virtual Thread executing a blocking operation inside a synchronized block cannot unmount from its carrier thread. JDK 24 solves this via JEP 491, but you need to be careful on JDK 21.

// Causes pinning on JDK 21 (not recommended)
synchronized (lock) {
    connection.read(); // Virtual thread is pinned to the carrier thread
}

// Prefer ReentrantLock instead
private final ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    connection.read(); // no pinning
} finally {
    lock.unlock();
}

Don’t pool Virtual Threads: the design philosophy of Virtual Threads is “one task, one thread.” Managing Virtual Threads with a thread pool is an anti-pattern.
ThreadLocal memory issues: every Virtual Thread has its own ThreadLocal copy. If you create a million Virtual Threads and each holds ThreadLocal data, memory overhead becomes significant. JDK 21 introduces Scoped Values (preview) as a replacement.

Pattern Matching for switch (JEP 441)

// Combined with sealed classes, the compiler performs exhaustive checks
public static double calculateArea(Shape shape) {
    return switch (shape) {
        case Circle c    -> Math.PI * c.radius() * c.radius();
        case Rectangle r -> r.width() * r.height();
        case Triangle t  -> 0.5 * t.base() * t.height();
        // No default needed: all subclasses of the sealed interface are covered
    };
}

// Pattern matching with guards
public static String classify(Shape shape) {
    return switch (shape) {
        case Circle c when c.radius() > 100   -> “big circle”;
        case Circle c                          -> “small circle”;
        case Rectangle r when r.width() == r.height() -> “square”;
        case Rectangle r                       -> “rectangle”;
        case Triangle t                        -> “triangle”;
    };
}

Record Patterns (JEP 440)

The diagram above shows the full evolution of pattern matching from JDK 14’s instanceof pattern to JDK 21’s Record destructuring and switch pattern matching.

record Point(int x, int y) {}
record Line(Point start, Point end) {}

// Nested destructuring
static void printLength(Object obj) {
    if (obj instanceof Line(Point(var x1, var y1), Point(var x2, var y2))) {
        double length = Math.sqrt(Math.pow(x2 - x1, 2) + Math.pow(y2 - y1, 2));
        System.out.printf(”Line length: %.2f%n”, length);
    }
}

Sequenced Collections (JEP 431)

Before JDK 21, getting the last element of a LinkedHashSet meant iterating the whole collection. The new interfaces unify operations on ordered collections:

SequencedCollection seq = new LinkedHashSet<>(List.of(”a”, “b”, “c”));
String first = seq.getFirst();    // “a”
String last = seq.getLast();      // “c”
SequencedCollection reversed = seq.reversed();  // [”c”, “b”, “a”]


SequencedMap seqMap = new LinkedHashMap<>();
seqMap.put(”one”, 1);
seqMap.put(”two”, 2);
Map.Entry firstEntry = seqMap.firstEntry();
Map.Entry lastEntry = seqMap.lastEntry();

2.6 The JDK 22–24 Transition

The diagram above shows the evolution of switch from the traditional JDK 8 statement to JDK 21’s full pattern matching — from fall-through semantics requiring break, to arrow syntax, yield expressions, and finally type patterns with guard conditions.

JDK 22: unnamed variables and patterns _ (JEP 456), statements allowed before super(...) (preview, JEP 447)

// Unnamed variables
try {
    int result = Integer.parseInt(input);
} catch (NumberFormatException _) {
    System.out.println(”Invalid number”);
}

// Unnamed patterns in switch
switch (shape) {
    case Circle _   -> System.out.println(”It’s a circle”);
    case Rectangle _ -> System.out.println(”It’s a rectangle”);
    default -> {}
}

JDK 23: primitive type pattern matching (preview, JEP 455), Markdown documentation comments (JEP 467)
JDK 24: Stream Gatherers finalized (JEP 485), Class-File API finalized (JEP 484), AOT class loading and linking (JEP 483), virtual threads without synchronized pinning (JEP 491)

Stream Gatherers is one of the most practical new features of JDK 24:

// JDK 24: custom intermediate operations
// Example: sliding window
List> windows = Stream.of(1, 2, 3, 4, 5)
    .gather(Gatherers.windowSliding(3))
    .toList();
// Result: [[1, 2, 3], [2, 3, 4], [3, 4, 5]]


// Example: fixed-size grouping
List> groups = Stream.of(1, 2, 3, 4, 5)
    .gather(Gatherers.windowFixed(2))
    .toList();
// Result: [[1, 2], [3, 4], [5]]

2.7 JDK 25: The Latest Features

JDK 25 was released on September 16, 2025, with 18 JEPs, 7 of which moved from preview/incubator to final features.

Compact Object Headers (JEP 519, final)

This is the core achievement of Project Lilliput. On 64-bit JVMs, each Java object header is compressed from 96–128 bits down to 64 bits (8 bytes). Measurements show heap memory usage drops 10–20%, and some benchmarks show 8% less CPU time.

# Enable Compact Object Headers (must be explicitly enabled in JDK 25)
java -XX:+UseCompactObjectHeaders -jar myapp.jar

# Inspect object layout (with the JOL tool)
# Before: 12-byte header (8B mark word + 4B compressed klass pointer)
# After:  8-byte header (mark word + class pointer merged)

How it works: the class pointer is compressed from 32 bits to 22 bits and stored together with the mark word in a single 64-bit word. This means the maximum number of supported classes drops from 2³² to roughly 4 million (2²²) — plenty for the vast majority of applications.

Scoped Values (JEP 506, final)

Scoped Values are the modern replacement for ThreadLocal, especially suited to Virtual Threads:

The diagram above shows the core design of Structured Concurrency — a parent task forks subtasks, and when any subtask fails the remaining siblings are automatically cancelled, dramatically simplifying concurrency control and error handling compared with the traditional independent-thread model.

// Define a ScopedValue
private static final ScopedValue CURRENT_USER = ScopedValue.newInstance();

// Bind it at the request entry point
public void handleRequest(HttpRequest request) {
    UserContext ctx = authenticate(request);
    ScopedValue.runWhere(CURRENT_USER, ctx, () -> {
        // Within this scope, any code can read CURRENT_USER
        processRequest(request);
    });
    // The scope ends and the value is released automatically; no memory leak risk
}
// Read it deep in the call chain
public void processRequest(HttpRequest request) {
    UserContext user = CURRENT_USER.get(); // read the value of the current scope
    // ...
}

The essential differences from ThreadLocal:

ScopedValue is immutable; ThreadLocal can be set at any time
ScopedValue has a well-defined lifetime (the scope); ThreadLocal requires manual remove
Inheriting a ScopedValue in a Virtual Thread costs nothing; ThreadLocal must be copied

Flexible Constructor Bodies (JEP 513, final)

Finally, statements are allowed before super():

public class ValidatedOrder extends Order {
    public ValidatedOrder(String orderId, BigDecimal amount) {
        // JDK 25: validation and field initialization before super()
        if (orderId == null || orderId.isBlank()) {
            throw new IllegalArgumentException(”orderId cannot be empty”);
        }
        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException(”amount must be positive”);
        }
        this.validatedAt = Instant.now(); // fields may be initialized
        super(orderId, amount); // then call the parent constructor
    }
}

Module Import Declarations (JEP 511, final)

// JDK 25: module-level import
import module java.base;  // imports all public types of the java.base module

// No more writing a pile of import java.util.*, import java.io.*, etc.
public class Demo {
    public static void main(String[] args) {
        var list = List.of(1, 2, 3);  // java.util.List
        var path = Path.of(”/tmp”);    // java.nio.file.Path
    }
}

Compact Source Files and Instance Main Methods (JEP 512, final)

// JDK 25: the simplest Hello World
void main() {
    println(”Hello, World!”);
}
// No public class, no static, no String[] args needed

Generational Shenandoah (JEP 521, final)

Shenandoah GC gains generational support. Similar to Generational ZGC, it separates young and old generation collection to improve throughput and reduce pause times.

Stable Values (JEP 502, preview)

Stable Values are a mechanism between final fields and ordinary fields: they allow lazy initialization while still letting the JVM treat them as constants for optimization:

// JDK 25 Preview
private final StableValue connection = StableValue.of();

public DatabaseConnection getConnection() {
    return connection.orElseSet(this::createConnection);
    // Initialized on first call; afterwards the JVM can treat it as a constant
}

AOT Method Profiling (JEP 515)

Part of Project Leyden: saves method-level profiling data and reuses it on subsequent startups to accelerate JIT warm-up:

# First run: collect profiling data
java -XX:AOTConfiguration=app.aotconf -jar myapp.jar
# Second run: reuse the profiling data to speed up
java -XX:AOTConfiguration=app.aotconf -jar myapp.jar

3. GC Garbage Collector Evolution

GC evolution is the most direct source of performance gains in JDK upgrades. The four LTS releases span Java GC’s journey from “usable” to “extreme.”

3.1 JDK 8: G1 Becomes an Option, CMS Is Still Mainstream

JDK 8’s default GC is Parallel GC (also called the Throughput Collector), suited to throughput-first batch scenarios. However, most web applications chose CMS or G1:

# Common JDK 8 GC configurations
# CMS (low-latency priority)
java -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled \
     -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly \
     -Xms4g -Xmx4g -jar myapp.jar

# G1 (balanced)
java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 \
     -XX:G1HeapRegionSize=8m -XX:InitiatingHeapOccupancyPercent=45 \
     -Xms4g -Xmx4g -jar myapp.jar

The main pain points of GC in the JDK 8 era:

CMS has the risk of concurrent mode failure; after triggering a Full GC, pauses can reach several seconds
CMS produces memory fragmentation; long-running processes need restarts
G1 wasn’t mature on JDK 8, and Full GC was single-threaded (only became multi-threaded in JDK 10)
PermGen space needs separate tuning, and OOMs were frequent

3.2 JDK 17: G1 Matures, ZGC Goes into Production

The diagram above shows G1’s region-based heap layout and its four-phase workflow — Young GC (evacuate Eden/Survivor) → concurrent marking → Mixed GC (reclaim some Old regions) → Full GC (fallback).

By JDK 17, the GC landscape had changed significantly:

G1 on JDK 17 is a qualitative leap compared with JDK 8:

NUMA-aware memory allocation (JDK 14, JEP 345)
Interruptible Mixed GC (JDK 12, JEP 344)
Parallel Full GC (JDK 10, JEP 307)
Automatically returns unused heap memory to the OS (JDK 12, JEP 346)

# Recommended G1 configuration on JDK 17
java -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=100 \
     -XX:G1HeapRegionSize=16m \
     -XX:G1NewSizePercent=20 \
     -XX:G1MaxNewSizePercent=40 \
     -XX:G1ReservePercent=15 \
     -XX:InitiatingHeapOccupancyPercent=35 \
     -Xms8g -Xmx8g -jar myapp.jar

# JDK 17 ZGC configuration (for ultra-low-latency scenarios)
java -XX:+UseZGC \
     -XX:ZCollectionInterval=5 \
     -XX:SoftMaxHeapSize=6g \
     -Xms8g -Xmx8g -jar myapp.jar

3.3 JDK 21: Generational ZGC

JDK 21 introduced Generational ZGC (JEP 439), a major upgrade to ZGC.

Why does ZGC need generations?

ZGC was originally non-generational, managing all objects uniformly. That means every GC must scan the entire heap. Although pause times are very short (sub-millisecond), the scanning overhead is high and throughput suffers. With generations:

Young generation collects frequently, with a small scope and high speed
Old generation collects rarely, greatly reducing scanning overhead
Overall throughput improves 10–20%

# JDK 21 generational ZGC
java -XX:+UseZGC -XX:+ZGenerational \
     -Xms16g -Xmx16g -jar myapp.jar

Measured data (an e-commerce order pipeline, 16 G heap, 8 cores):

As you can see, generational ZGC not only keeps pauses extremely low, it also pushes throughput above G1.

3.4 JDK 25: Further GC Optimization

JDK 25’s GC changes:

Generational Shenandoah (JEP 521, final): like ZGC, Shenandoah gains generational support. Introduced as experimental in JDK 24 and finalized in JDK 25.
Non-generational ZGC removed (JDK 24, JEP 490): starting with JDK 24, ZGC only has generational mode; -XX:+ZGenerational is no longer needed (nor accepted), and generational is the default.
Compact Object Headers (JEP 519) impact on GC: a smaller object header means less metadata for every GC to process, making the mark phase faster.

# Recommended ZGC configuration on JDK 25
java -XX:+UseZGC \
     -XX:+UseCompactObjectHeaders \
     -Xms16g -Xmx16g -jar myapp.jar

# JDK 25 Shenandoah generational mode
java -XX:+UseShenandoahGC \
     -XX:ShenandoahGCMode=generational \
     -Xms16g -Xmx16g -jar myapp.jar

3.5 GC Selection Guide

A real GC migration case:

We had an order service on JDK 8 + CMS with an 8 G heap. Every afternoon during peak traffic, CMS would frequently hit concurrent mode failure, trigger Full GC, pause for 3–5 seconds, and directly cause timeouts at the upstream gateway.

After migrating to JDK 17 + G1, P99 GC pauses dropped below 50 ms and concurrent mode failure disappeared entirely. Later we upgraded further to JDK 21 + Generational ZGC + 16 G heap, where P99 fell to 0.5 ms — business code essentially can’t perceive GC anymore.

4. Performance Optimization and JIT Compilation

4.1 JIT Compiler Evolution

The JDK’s JIT (Just-In-Time) compiler compiles hot bytecode into machine code. Understanding JIT’s evolution is critical for performance tuning.

Tiered compilation in JDK 8

JDK 8 uses two compilers, C1 (Client Compiler) and C2 (Server Compiler), cooperating through tiered compilation:

Level 0: interpreted execution
Level 1: C1 compilation, no profiling
Level 2: C1 compilation, limited profiling
Level 3: C1 compilation, full profiling
Level 4: C2 compilation (final optimized code)

# JDK 8: view JIT compilation logs
java -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions \
     -XX:+PrintInlining -jar myapp.jar

The Graal compiler experiment of JDK 10–17

JDK 10 introduced Graal as an experimental JIT compiler (JEP 317), written in Java and theoretically easier to maintain and extend. But JDK 17 removed the Graal JIT interfaces (JEP 410) because Oracle shifted Graal’s development focus to the GraalVM project.

Continuous C2 optimization in JDK 21–25

No new JIT compiler was introduced, but C2 has been continuously improved version by version:

Better auto-vectorization
Enhanced escape analysis, with more objects allocated on the stack
More intrinsic methods; common operations map directly to CPU instructions

4.2 Startup Speed Optimization

Startup speed is critical in serverless and containerized scenarios. Startup optimization across versions:

CDS (Class Data Sharing) evolution

# JDK 17: dynamic CDS
# First run, generate the archive
java -XX:ArchiveClassesAtExit=app-cds.jsa -jar myapp.jar
# Subsequent runs, use the archive
java -XX:SharedArchiveFile=app-cds.jsa -jar myapp.jar
# Startup improves 20-40%

# JDK 24+: AOT class loading and linking
java -XX:AOTCache=app.aot -XX:AOTConfiguration=app.aotconf -jar myapp.jar
# Startup can improve up to 40-60%

Measured startup times (Spring Boot 3.x application, medium size, 50 beans):

4.3 Memory Model Changes

Compact Strings (JDK 9, JEP 254)

JDK 8’s String internally uses char[] (2 bytes per character, UTF-16). JDK 9 changed it to byte[] + an encoding flag, so Latin-1 strings use only 1 byte per character:

// JDK 8: String internals
private final char[] value; // 2 bytes per character

// JDK 9+: String internals
private final byte[] value; // 1 byte per character for Latin-1
private final byte coder;   // 0 = Latin-1, 1 = UTF-16

For applications that are mostly English and numbers (most backend services), String memory usage is cut in half. One of our log-analysis services dropped its heap usage from 6 G to 4.2 G after upgrading to JDK 11.

The diagram above illustrates the memory optimization of Compact Strings (JEP 254) — JDK 8’s char[] is a fixed 2 bytes per character, while JDK 9+’s byte[] + coder needs only 1 byte per Latin-1 character, halving memory in English-heavy scenarios.

PermGen → Metaspace

JDK 8 replaced PermGen with Metaspace (native memory, not heap memory):

No more java.lang.OutOfMemoryError: PermGen space
No upper limit by default (configurable via -XX:MaxMetaspaceSize)
More efficient class unloading

The memory impact of JDK 25 Compact Object Headers

Minimum size of a Java object:

JDK 8–24 (with compressed pointers): 12 B header + alignment padding = 16 B
JDK 25 (Compact Headers): 8 B header + alignment padding = 16 B (still 16 B minimum due to alignment)

But for slightly larger objects (with 1–2 fields), the difference shows:

// An object with one int field
// JDK 8-24:  header(12B) + int(4B) = 16B
// JDK 25:    header(8B) + int(4B) + padding(4B) = 16B
// No difference in this case
// An object with int + boolean fields
// JDK 8-24:  header(12B) + int(4B) + boolean(1B) + padding(7B) = 24B
// JDK 25:    header(8B) + int(4B) + boolean(1B) + padding(3B) = 16B
// Saves 8B (33%)

When your application has lots of small objects (DTOs, Events, Node nodes), the gains from Compact Object Headers are significant.

5. The Module System (JPMS)

JPMS (Java Platform Module System) is the core deliverable of Project Jigsaw introduced in JDK 9. To be blunt: as of 2025, most business projects still don’t use the module system. But it’s important to understand, because it affects access control over JDK internal APIs and many migration issues.

Basic structure of module-info.java:

module com.myapp.order {
    // Declare dependencies
    requires java.sql;
    requires java.logging;
    requires transitive com.myapp.common; // transitive dependency

// Export packages (only exported packages are accessible to other modules)
    exports com.myapp.order.api;
    exports com.myapp.order.model;
    // Open reflection to specific modules (for frameworks such as Jackson, Hibernate)
    opens com.myapp.order.entity to com.fasterxml.jackson.databind;
    opens com.myapp.order.entity to org.hibernate.orm.core;
    // SPI service declarations
    provides com.myapp.common.spi.PaymentProvider
        with com.myapp.order.payment.AlipayProvider;
    uses com.myapp.common.spi.NotificationService;
}

Why don’t most projects use modules?

Spring Framework’s compatibility strategy: Spring relies heavily on reflection and dynamic proxies, which conflict with the module system’s strong encapsulation. Although Spring 5+ provides Automatic-Module-Name, full modularization has never been a priority.
Third-party libraries are poorly modularized: many common libraries are still unnamed or automatic modules, and mixing them easily leads to split-package problems.
Cost/benefit mismatch: for most business applications, package access control plus Maven/Gradle dependency management is enough; JPMS’s strong isolation doesn’t pay off.

But JPMS’s impact on the JDK itself is profound:

Starting with JDK 16, the --illegal-access option was removed and JDK internal APIs are strongly encapsulated by default. If your code or dependencies directly use internal APIs like sun.misc.Unsafe or com.sun.xml.internal.*, you must handle them when upgrading:

# Temporary workaround: add --add-opens (not recommended long-term)
java --add-opens java.base/java.lang=ALL-UNNAMED \
     --add-opens java.base/sun.nio.ch=ALL-UNNAMED \
     -jar myapp.jar

# Correct approach: replace with public APIs
# sun.misc.Unsafe → VarHandle (JDK 9+)
# sun.misc.BASE64Encoder → java.util.Base64 (JDK 8+)
# sun.reflect.Reflection → StackWalker (JDK 9+)

6. Core API Changes

6.1 Collection Factory Methods

// JDK 8: creating immutable collections
List list = Collections.unmodifiableList(Arrays.asList(”a”, “b”, “c”));
Map map = Collections.unmodifiableMap(new HashMap<>() {{
    put(”one”, 1);
    put(”two”, 2);
}});

// JDK 9+: collection factory methods
List list = List.of(”a”, “b”, “c”);
Set set = Set.of(”a”, “b”, “c”);
Map map = Map.of(”one”, 1, “two”, 2);
Map mapFromEntries = Map.ofEntries(
    Map.entry(”one”, 1),
    Map.entry(”two”, 2),
    Map.entry(”three”, 3)
);
// JDK 10+: Collectors.toUnmodifiableList
List filtered = list.stream()
    .filter(s -> s.startsWith(”a”))
    .collect(Collectors.toUnmodifiableList());
// JDK 16+: Stream.toList() (returns an unmodifiable List)
List filtered = list.stream()
    .filter(s -> s.startsWith(”a”))
    .toList();
// JDK 21: SequencedCollection
SequencedCollection seqList = new ArrayList<>(List.of(”a”, “b”, “c”));
seqList.addFirst(”z”);
seqList.addLast(”d”);
String first = seqList.getFirst(); // “z”
String last = seqList.getLast();   // “d”

6.2 HttpClient

JDK 8’s HttpURLConnection is widely considered a terrible API. JDK 11 standardized the brand-new HttpClient (JEP 321).

The diagram above compares the architecture of JDK 8’s HttpURLConnection (blocking, verbose, no HTTP/2) with JDK 11+’s HttpClient (async, HTTP/2, fluent API).

// JDK 8: HttpURLConnection (the painful way)
URL url = new URL(”https://api.example.com/users”);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod(”GET”);
conn.setRequestProperty(”Accept”, “application/json”);
conn.setConnectTimeout(5000);
conn.setReadTimeout(10000);


int responseCode = conn.getResponseCode();
if (responseCode == 200) {
    try (BufferedReader br = new BufferedReader(
            new InputStreamReader(conn.getInputStream()))) {
        StringBuilder response = new StringBuilder();
        String line;
        while ((line = br.readLine()) != null) {
            response.append(line);
        }
        System.out.println(response.toString());
    }
} else {
    // error handling...
}
conn.disconnect();
// JDK 11+: HttpClient (the modern way)
HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2)
    .connectTimeout(Duration.ofSeconds(5))
    .followRedirects(HttpClient.Redirect.NORMAL)
    .build();
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create(”https://api.example.com/users”))
    .header(”Accept”, “application/json”)
    .timeout(Duration.ofSeconds(10))
    .GET()
    .build();
// Synchronous call
HttpResponse response = client.send(request,
    HttpResponse.BodyHandlers.ofString());
System.out.println(response.body());
// Asynchronous call
client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
    .thenApply(HttpResponse::body)
    .thenAccept(System.out::println)
    .exceptionally(e -> { e.printStackTrace(); return null; });
// POST JSON
HttpRequest postRequest = HttpRequest.newBuilder()
    .uri(URI.create(”https://api.example.com/users”))
    .header(”Content-Type”, “application/json”)
    .POST(HttpRequest.BodyPublishers.ofString(”“”
        {”name”: “Zhang San”, “email”: “zhangsan@example.com”}
        “”“))
    .build();

6.3 Foreign Function & Memory API

The FFM API (Foreign Function & Memory API) is the core deliverable of Project Panama, aimed at replacing JNI (Java Native Interface). It started incubating in JDK 14 and was finalized in JDK 22.

// JDK 22+: call strlen from the C standard library via the FFM API
import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;

public class FFMExample {
    public static void main(String[] args) throws Throwable {
        // Get the system linker
        Linker linker = Linker.nativeLinker();

        // Look up the strlen function in the C standard library
        SymbolLookup stdlib = linker.defaultLookup();
        MemorySegment strlenAddr = stdlib.find(”strlen”).orElseThrow();
        // Create a method handle
        MethodHandle strlen = linker.downcallHandle(
            strlenAddr,
            FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS)
        );
        // Allocate and use native memory
        try (Arena arena = Arena.ofConfined()) {
            MemorySegment cString = arena.allocateFrom(”Hello, FFM!”);
            long length = (long) strlen.invoke(cString);
            System.out.println(”String length: “ + length); // prints: 11
        }
        // The Arena releases native memory automatically when closed; no leaks
    }
}

Compared with JNI:

Safety: the FFM API manages memory lifetimes at the Java level; JNI requires manual C memory management
Developer efficiency: the FFM API is pure Java; JNI requires writing C/C++ code plus header files
Performance: the FFM API performs on par with JNI, and is better in some cases (it avoids JNI’s boundary-crossing overhead)
Tooling: the jextract tool can auto-generate Java bindings from C header files

6.4 Other Important API Changes

Process API enhancements (JDK 9)

// JDK 9+: get process information
ProcessHandle current = ProcessHandle.current();
System.out.println(”PID: “ + current.pid());
System.out.println(”Command: “ + current.info().command().orElse(”unknown”));
System.out.println(”CPU Duration: “ + current.info().totalCpuDuration().orElse(Duration.ZERO));

// List all child processes
current.children().forEach(ph ->
    System.out.println(”Child PID: “ + ph.pid()));

CompletableFuture enhancements

// JDK 9: orTimeout, completeOnTimeout
CompletableFuture future = callRemoteService()
    .orTimeout(5, TimeUnit.SECONDS)          // throws TimeoutException after 5 seconds
    .completeOnTimeout(”default”, 5, TimeUnit.SECONDS); // returns a default value on timeout

// JDK 9: copy()
CompletableFuture defensiveCopy = future.copy(); // prevents external code from completing it
// JDK 12: exceptionallyCompose
CompletableFuture resilient = callPrimaryService()
    .exceptionallyCompose(ex -> callFallbackService());

Ongoing Stream API enhancements

// JDK 9: takeWhile, dropWhile
Stream.of(1, 2, 3, 4, 5, 1, 2)
    .takeWhile(n -> n < 4)     // [1, 2, 3]
    .forEach(System.out::println);


// JDK 9: ofNullable
Stream stream = Stream.ofNullable(getNullableValue()); // null-safe
// JDK 16: Stream.toList()
List list = Stream.of(1, 2, 3).toList(); // replaces collect(Collectors.toList())
// JDK 16: mapMulti
Stream.of(1, 2, 3)
    .mapMulti((num, consumer) -> {
        consumer.accept(num);
        consumer.accept(num * 10);
    })
    .toList(); // [1, 10, 2, 20, 3, 30]

7. Security Enhancements

Security changes are often overlooked, but in production they can cause SSL handshake failures or make encryption algorithms unavailable right after an upgrade.

JDK 25 security features worth special attention:

Quantum-resistant algorithm ML-DSA: the Module-Lattice-Based Digital Signature Algorithm introduced in JDK 24, following the NIST FIPS 204 standard, preparing for the post-quantum computing era
Key Derivation Function API (JEP 506): a standardized key derivation function API
PEM Encodings (JEP 470, preview): PEM encoding support for cryptographic objects

Security pitfalls when migrating:

# Problem: after upgrading from JDK 8 to JDK 17, connections to legacy SSL services fail
# Cause: JDK 17 disables TLS 1.0/1.1 and weak cipher algorithms by default
# Temporary workaround (not recommended long-term):
java -Djdk.tls.disabledAlgorithms=”“ -jar myapp.jar

# Correct approach: upgrade the TLS configuration on the peer side

The impact of strong encapsulation:

Starting with JDK 17, the --illegal-access option is completely removed. All reflective access to JDK internal APIs is denied by default. This directly affects frameworks such as Spring, Hibernate, and Lombok. Minimum supported versions:

8. Production Migration Practice

8.1 JDK 8 → JDK 17 Migration

This was the largest and most painful migration. Here are the main pitfalls our team hit:

Step 1: Dependency analysis

# Use jdeps to analyze your code’s dependencies on JDK internal APIs
jdeps --jdk-internals -R --class-path ‘libs/*’ myapp.jar

# Example output:
# myapp.jar -> java.base
#    com.myapp.util.UnsafeHelper -> sun.misc.Unsafe  JDK internal API (jdk.unsupported)
#    com.myapp.xml.Parser -> com.sun.org.apache.xerces.internal.jaxp JDK internal API

Step 2: Handle breaking changes

Core issue checklist:

Step 3: Spring Boot upgrade path

If you use Spring Boot, the upgrade path is:

Spring Boot 2.x (JDK 8)
  → Spring Boot 2.7.x (JDK 17 compatible mode)
  → Spring Boot 3.0+ (JDK 17 native support, javax → jakarta)

The javax → jakarta migration in Spring Boot 3.0 is the biggest chunk of work. You can automate it with OpenRewrite:



    org.openrewrite.maven
    rewrite-maven-plugin
    5.37.0
    
        
            org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_0
        
    
    
        
            org.openrewrite.recipe
            rewrite-spring
            5.16.0

# Run the automated migration
mvn rewrite:run

Step 4: Clean up JVM arguments

Many JDK 8 JVM arguments were removed or changed in JDK 17:

# JDK 8 argument → how to handle it on JDK 17
-XX:+UseConcMarkSweepGC     → removed (CMS is gone), use -XX:+UseG1GC
-XX:+UseParNewGC             → removed, G1 handles it automatically
-XX:CMSInitiatingOccupancyFraction=75 → removed
-XX:+PrintGCDetails          → use -Xlog:gc*
-XX:+PrintGCDateStamps       → use -Xlog:gc*:time
-XX:+UseGCLogFileRotation    → use -Xlog:gc*:file=gc.log:time:filecount=5,filesize=10m
-XX:PermSize=256m            → removed (PermGen no longer exists)
-XX:MaxPermSize=512m         → removed (optionally -XX:MaxMetaspaceSize)


# Typical JDK 8 JVM arguments
java -Xms4g -Xmx4g \
     -XX:+UseConcMarkSweepGC \
     -XX:+CMSParallelRemarkEnabled \
     -XX:CMSInitiatingOccupancyFraction=75 \
     -XX:+UseCMSInitiatingOccupancyOnly \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps \
     -Xloggc:/var/log/gc.log \
     -XX:PermSize=256m \
     -XX:MaxPermSize=512m \
     -jar myapp.jar


# Equivalent JDK 17 JVM arguments
java -Xms4g -Xmx4g \
     -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=100 \
     -Xlog:gc*:file=/var/log/gc.log:time:filecount=5,filesize=20m \
     -XX:MaxMetaspaceSize=512m \
     --add-opens java.base/java.lang=ALL-UNNAMED \
     -jar myapp.jar

8.2 JDK 17 → JDK 21 Migration

Compared with 8 → 17, this migration is much smoother. Main focus points:

Virtual Threads adoption strategy: don’t roll it out everywhere at once. Pilot it on non-critical paths first, confirm there are no pinning issues, then scale.
Sequenced Collections: purely additive, no breaking changes.
Pattern Matching for switch: gradually replace if-else chains.

# Migration example: enabling Virtual Threads in Spring Boot
# application.yml (Spring Boot 3.2+)
spring:
  threads:
    virtual:
      enabled: true
# This one line makes Tomcat handle requests with Virtual Threads

JDK 21 GC migration advice:

# If you use G1 on JDK 17, you can keep it on JDK 21
# If you want to try Generational ZGC:
java -XX:+UseZGC -XX:+ZGenerational -Xms8g -Xmx8g -jar myapp.jar
# Note: ZGC needs more off-heap memory; we recommend sizing the container
# memory at 1.5-2x the heap

8.3 Performance Benchmark Comparison

Below are our measured results on identical hardware (8 cores, 16 G, Intel Xeon E5–2686 v4):

Throughput test (simulated e-commerce order API, 100 concurrent users for 5 minutes):

COH = Compact Object Headers

Data points worth noting:

JDK 8 → JDK 17 (G1): QPS up ~23%, P99 down ~38%
JDK 17 → JDK 21 (G1): QPS up ~7%, long-tail latency clearly improved
ZGC’s P999 is 4x better than G1, but needs a larger heap
Compact Object Headers add ~5% throughput in scenarios with lots of small objects

9. Version Selection Recommendations

Decision matrix:

My advice:

If you’re still on JDK 8: it’s 2025 — upgrade as soon as possible. JDK 8’s public updates ended in 2019 (Oracle JDK), and security patches now depend on third-party distributions. Aim straight for JDK 21 or JDK 25, because the incremental migration cost from JDK 17 to JDK 21 is very low.
If you’re on JDK 17: JDK 21’s Virtual Threads is a reason to upgrade, especially for I/O-bound applications. JDK 25, as the newest LTS, is even better.
New projects: use JDK 25 directly.
Spring Boot compatibility quick reference:
Spring Boot 3.0–3.1: JDK 17 minimum, supports through JDK 20
Spring Boot 3.2–3.3: JDK 17 minimum, supports through JDK 22
Spring Boot 3.4+: JDK 17 minimum, supports through JDK 25

References

JDK 8 Features — Oracle
JDK 17 Release Notes — Oracle
JDK 21 JEP Index — OpenJDK
JDK 25 JEP Index — OpenJDK
JEP 444: Virtual Threads
JEP 439: Generational ZGC
JEP 519: Compact Object Headers
JEP 506: Scoped Values
JEP 513: Flexible Constructor Bodies
JEP 512: Compact Source Files and Instance Main Methods
JEP 511: Module Import Declarations
JEP 521: Generational Shenandoah
JEP 515: AOT Method Profiling
JEP 502: Stable Values (Preview)
JEP 485: Stream Gatherers
JEP 484: Class-File API
JEP 491: Synchronize Virtual Threads without Pinning
JEP 483: Ahead-of-Time Class Loading & Linking
JEP 490: Remove Non-Generational ZGC
JEP 497: Quantum-Resistant ML-DSA
JEP 254: Compact Strings
JEP 310: Application Class-Data Sharing
JEP 350: Dynamic CDS Archives
Project Loom — OpenJDK
Project Panama — OpenJDK
Project Leyden — OpenJDK
Project Valhalla — OpenJDK
Project Lilliput — OpenJDK
Spring Boot System Requirements
OpenRewrite Spring Boot 3 Migration

No More "if (object == null)" in Our Java Project, and I Got Rewarded by My Boss

Dylan Smith — Sat, 01 Aug 2026 09:17:00 GMT

Subscribe now

Recently, a friend of mine joined a new company. Since there was a lot of code in the project that directly judged whether an object is null. So my friend optimized it by using Optional and was praised by the boss.

Now let’s introduce it in detail.

In the previous article we have introduced Lambda expression in java. In this article, I will introduce how to combine Lambda expression and Optional make Java handle null more gracefully.

Suppose we have a student object，and an Optional wrapper for the student object:

public class OptionalTest {

    public static void main(String[] args) {
        Student student = new Student(”Bob”, 18);
        Optional studentOpt = Optional.ofNullable(student);
    }

    @Getter
    @AllArgsConstructor
    public static class Student {
        private String name;
        private Integer age;
    }
}

Optional cannot make the original cumbersome null check simpler if it is not used in conjunction with Lambda，such as

//writing method 1if (student == null) {
  return UNKNOWN_STUDENT;
} else {
  return student;
}

//writing method 2 is just as bad as writing method 1
if (!studentOpt.isPresent()) {
  return UNKNOWN_STUDENT;
} else {
  return studentOpt.get();
}

Only when Optional is used in combination with Lambda can its true power be exerted!

Let’s now compare the following four common null handling differences between Java8’s Lambda + Optional and traditional Java.

Situation 1 — Start if it exists

// if
if (student != null) {
  System.out.println(student);
}

// Optinal
studentOpt.ifPresent(System.out::println);

Case 2 — Return if it exists, if not return fart or throw exception

// if
if (student == null) {
  return UNKNOWN_STUDENT;   // or throw exception
} else {
  return student;
}

// Optinal
return studentOpt.orElse(UNKNOWN_STUDENT);
return studentOpt.orElseThrow(RuntimeException::new);

Case 3 — If it exists, it is returned. If not, it is generated by the function

// if
if (student == null) {
  return UNKNOWN_STUDENT;
} else {
  return generateWithFunction();
}

// Optinal
return studentOpt.orElseGet(() -> generateWithFunction());

Case 4 — Continuous null checks

public class OptionalCase {


    public static void main(String[] args) {
        Student student = new Student(”Bob”, 18,
                new Street(”Main Street”, new City(”Los Angeles”, new State(”CA”))));

        System.out.println(getStateFromJava7(student));
        System.out.println(getStateFromJava8(student));
    }

    private static String getStateFromJava7(Student student) {
        // Java 7
        if (student != null) {
            Street street = student.getAddress();
            if (street != null) {
                City city = street.getCity();
                if (city != null) {
                    State state = city.getState();
                    if (state != null) {
                        String stateName = state.getName();
                        if (stateName != null) {
                            return stateName;
                        }
                        return “unknown”;
                    }
                    return “unknown”;
                }
                return “unknown”;
            }
            return “unknown”;
        }
        return “unknown”;
    }

    private static String getStateFromJava8(Student student) {
        Optional studentOpt = Optional.ofNullable(student);
        // Java 8
        return studentOpt
                .map(Student::getAddress)
                .map(Street::getCity)
                .map(City::getState)
                .map(State::getName)
                .orElse(”unknown”);
    }

    @Getter
    @AllArgsConstructor
    static class Student {
        private String name;
        private Integer age;
        private Street address;
    }

    @Getter
    @AllArgsConstructor
    static class Street {
        private String name;
        private City city;
    }

    @Getter
    @AllArgsConstructor
    static class City {
        private String name;
        private State state;
    }

    @Getter
    @AllArgsConstructor
    static class State {
        private String name;
    }
}

It can be clearly seen from the above four situations that Optional + Lambda allows us to write a lot less if-Else blocks. Especially for situation 4, the traditional Java writing method seems lengthy and difficult to understand, while Optional+Lambda is refreshing, clear and concise.

Share Java, SpringBoot & AI Development: Coding Skills & Interview

If this post has helped you out in any way, I’d truly appreciate you becoming a paid subscriber. Your ongoing support keeps me motivated to keep crafting more thorough, high-quality technical content down the line. Thank you so much.

Deep Dive Into Java Stream Collect: A Comprehensive Full Explanation

Dylan Smith — Sat, 01 Aug 2026 09:00:11 GMT

Subscribe now

In the previous article，Mastering Java Stream in One Article, we have explained the overall situation of Stream in detail, and also roughly introduced the common usage of the collect method, but this is just the tip of the iceberg.

This article will specifically analyze the collect operation and unlock more advanced usage, making the Stream operation truly a magic weapon in our coding.

Let’s start from an example and expand the definition of Student class.

@Getter
@AllArgsConstructor
public static class Student {
    private String department;
    private String name;
    private Integer age;
    private String sex;
  
    @Override
    public String toString() {
      return “Student{name=’” + name + “’, department=” + department + “’, age=” + age + “’, sex=” + sex + “}”;
    }
}

We now have a group of students with the following information:

List allStudents = Lists.newArrayList(
      new Student(”Computer”, “Bob”, 18, “male”),
      new Student(”Computer”, “Ted”, 17, “male”),
      new Student(”Economics”, “Zeka”, 19, “male”),
      new Student(”Economics”, “Alan”, 19, “male”),
      new Student( “Computer”, “Anne”, 21, “female”),
      new Student(”Physics”, “Davis”, 21, “female”)
);

You need to implement such a requirement:

In the given list of students, filter out all the students in the computer department.

If you have ever used Stream, or if you have read my previous article on Stream, then the above claims can be easily achieved with the help of Stream:

public void filterComputerDepartmentStudents(List students) {
        List computerStudents = students.stream()
                .filter(s -> Objects.equals(s.getDepartment(), “Computer”))
                .collect(Collectors.toList());
        System.out.println(computerStudents);
    }

Easy peasy! But don’t get too happy, the actual needs are often not so simple, for example, the demand now becomes this

In the given list of students, filter out all computer science students and group them by gender

In fact, it just adds a new grouping requirement, a small change! It only needs to be processed in two steps. First, follow the logic of the previous code and then group the results:

public void filterComputerStudentsGroupBySex(List students) {
    // step1, filter
    List computerStudents = students.stream()
            .filter(s -> Objects.equals(s.getDepartment(), “Computer”))
            .collect(Collectors.toList());

    // step2, group
    Map> resultMap = new HashMap<>();
    for (Student student : computerStudents) {
        List groupList = resultMap.computeIfAbsent(student.getDepartment(), s -> new ArrayList<>());
        groupList.add(student);
    }
}

It does not seem to be a problem, and I believe that many of my friends are actually coding in the same way. But in fact, we can also use the Stream operation is done directly:

public void filterComputerGroupByStream(List students) {
        Map> resultMap = students.stream()
                .filter(s -> Objects.equals(s.getDepartment(), “Computer”))
                .collect(Collectors.groupingBy(Student::getSex));
        System.out.println(resultMap);
    }

Isn’t that cool? One line of code does it all! Doesn’t writing code like this feel like writing a requirements document that describes what I want, not how to do it?

Both of the above would result in the following.

{
  female=[Student{name=’Anne’, department=’Computer’, age=21’, sex=’female’}], 
  male=[Student{name=’Bob’, department=’Computer’, age=18’, sex=’male’}, Student{name=’Ted’, department=’Computer’, age=17’, sex=’male’}]
}

Let’s take a closer look at collect and unlock more ways to use it.

Introduction to collect

I believe that when you first come into contact with Stream collect, you will suddenly see the concepts of collect, Collector, and Collectors. It is easy for you to confuse them. Let’s take a look at their differences and connections respectively;

collect: This is one of the termination methods of Stream. The accepted parameter is a specific implementation class of the Collector interface, and the collector is used to perform related operations on the data entering the collect;
Collector：It is an interface, which is the input parameter of the collect method;
Collectors：It is a tool class that provides many specific implementation classes of the Collector interface, which are some more general collectors preset for convenience of use (of course, you can implement the Collector interface yourself without using the implementation provided by the Collectors class).

Let’s take the simplest usage scenario of collect and look at the relationship between the three to deepen our understanding. As shown in the figure below:

Use of Collector

In fact, it can be seen that Collector is the most important concept of them all, which controls what kind of processing logic is to be carried out and can be categorized into the following three groups:

1.Collection type

This is the most commonly used type. After a series of intermediate operations, the remaining elements are taken out of the Stream and placed directly into the collection object.

The Collectors tool class preset provides three methods that return collection types, as follows:

2.Single result type

For the operation of a single result type, the elements in the Stream are traversed one by one, into the Collector processing function, and then it will be merged with the processing result of the previous element to process and get a new result, and so on, until the output of the final result.

For example, the processing logic of Collectors.maxBy() is shown below:

The execution logic of methods such as minBy(), summingInt(), etc. is much the same as theirs, essentially processing them one by one to produce a final result.

Let’s recall the example mentioned in the previous article to find the maximum age of the football team students. Now we can achieve it like this:

List footballStudent = Lists.newArrayList(
                new Student(”Alan”, 19),
                new Student(”Anne”, 21),
                new Student(”Davis”, 21));

//Collectors.maxBy()
footballStudent.stream()
                .map(Student::getAge)
                .collect(Collectors.maxBy(Comparator.comparingInt(a -> a)))
                .ifPresent(a -> System.out.println(”The maximum age for a football team is “ + a));

However, in fact, this method is not recommended. For the convenience of use, JDK provides a simplified encapsulation of the above logic. We can directly use the max() method to implement it, that is, the above code is equivalent to the following writing:

footballStudent.stream()
    .map(Student::getAge)
    .max(Comparator.comparing(a -> a))
    .ifPresent(a -> System.out.println(”The maximum age for a football team is “ + a));

In fact, your idea will also give prompts for inappropriate code, and a wavy line will appear under this part of the code.

You can optimize with one click through option + enter 😁.

3.Grouping type

Grouping operation is an extremely important usage scenario of collect. The Collectors tool class provides the groupingBy() method to obtain a grouping operation Collector. The groupingBy() operation requires specifying two key inputs, namely Classification Function and Value Collector:

Classification function : used for processing based on the specified elements, return a value for grouping (i.e., the Key of the grouping result Map), for the function after processing the return value of the same elements, will be assigned to the same group.
Value Collector: For further processing logic of grouped data elements, this is still a regular Collector, which is exactly the same as the collector passed in the collect() method (as can be seen, There can be nested logic here, which will be introduced in detail later).

For ease of use, two overloaded implementations of groupingBy are provided in the Collectors tool class. One of the methods only needs to pass in a classification function. This is because it uses toList() as the value collector by default, as follows:

When it is just a basic grouping, just pass in a classification function, just like the example at the beginning of the article, here is the code:

public void filterComputerGroupByStream(List students) {
        Map> resultMap = students.stream()
                .filter(s -> Objects.equals(s.getDepartment(), “Computer”))
                .collect(Collectors.groupingBy(Student::getSex));
        System.out.println(resultMap);
    }

Let’s take this code as an example and look at its execution logic diagram:

When you not only need to group, but also need to perform some additional processing on the grouped data, you need to provide both a classification function and a value collector:

public static void filterComputerGroupByStream(List students) {
        Map resultMap = students.stream()
                .filter(s -> Objects.equals(s.getDepartment(), “Computer”))
                .collect(Collectors.groupingBy(Student::getSex, Collectors.counting()));
        System.out.println(resultMap);
    }

Output:

{female=1, male=2}

In the above code, Collectors.groupingBy() is a grouping Collector, and a Collectors.counting() is passed in. It also returns a Collector, which means that one Collector is nested in another. Collector.

Advanced usage of overlays

Let’s look at a more complex scenario. The previous request was to filter out students from the computer department and then group them according to gender.

Now the requirement is not limited to the computer department. It is required to first group the students by department, then group them by gender, and return all corresponding numbers.

At first glance, of course we cannot process each department separately. With the help of the collect operation, we can achieve this:

public static void groupByDepartmentAndSex(List students) {
        Map> resultMap = students.stream()
                .collect(Collectors.groupingBy(Student::getDepartment,
                        Collectors.groupingBy(Student::getSex,
                                Collectors.counting())));
        System.out.println(resultMap);
    }

Output:

{
  Economics={male=2}, 
  Computer={female=1, male=2}, 
  Physics={female=1}
}

If you wish, you can continue to nest to complete more complex requirements.

Use of partitioningBy

For the requirement of grouping according to gender, since gender has only two values, it can actually be considered as a bool value, that is, the grouping key is of bool type. In this case, we can also achieve this requirement through the Collectors.partitioningBy() method, as follows:

public static void partitioningBySex(List students) {
        Map> resultMap = students.stream()
                .collect(Collectors.groupingBy(Student::getDepartment,
                        Collectors.partitioningBy(s -> Objects.equals(s.getSex(), “male”),
                                Collectors.counting())));
        System.out.println(resultMap);
    }

true means male, false means female,

Output:

{
  Economics={false=0, true=2}, 
  Computer={false=1, true=2}, 
  Physics={false=1, true=0}
}

From a purely usage perspective, the return value of the classification function of the grouping collector is Boolean, so the effects of Collectors.partitioningBy() and Collectors.groupingBy() are basically the same.

Use of collectAndThen

The collector corresponding to collectAndThen, in addition to passing in a downstream that is actually used for result collection and processing, also needs to pass in a finisher method. After downstream calculates the result, the finisher method is used to perform secondary processing on the result. Process and return the processing results as final data.

Let’s look at an example like this

After grouping according to departments, then grouping according to gender, taking the age of the oldest student in each group.

public static void getOldestStudentGroup(List students) {
        Map>> resultMap = students.stream()
                .collect(Collectors.groupingBy(Student::getDepartment,
                        Collectors.partitioningBy(s -> Objects.equals(s.getSex(), “male”),
                                Collectors.maxBy(Comparator.comparing(Student::getAge)))));
        System.out.println(”The oldest male student in the Computer Department is: “
                + resultMap.get(”Computer”).get(true).map(Student::getAge).orElse(0));
    }

Output:

The oldest male student in the Computer Department is: 18

It is worth noting that the object returned after processing by maxBy() here is wrapped by Optional. In order to get the final value, we need to perform some additional operations.

In most cases, we expect to get the final value directly instead of the Optional object. In this case, we can use collectAndThen to get the purpose.

public static void collectAndThen(List students) {
        Map> resultMap = students.stream()
                .collect(Collectors.groupingBy(Student::getDepartment,
                        Collectors.partitioningBy(s -> Objects.equals(s.getSex(), “male”),
                                Collectors.collectingAndThen(Collectors.maxBy(Comparator.comparing(Student::getAge)),
                                        a -> a.map(Student::getAge).orElse(0)))));
        System.out.println(resultMap);
        System.out.println(”The oldest male student in the Computer Department is: “ + resultMap.get(”Computer”).get(true));
    }

Output:

{
  Economics={false=0, true=19}, 
  Computer={false=21, true=18}, 
  Physics={false=21, true=0}
}
The oldest male student in the Computer Department is: 18

How does it feel to get it right in one step? Isn’t it very comfortable?😄

Custom collector

Although the Collectors tool class provides many commonly used collectors, perhaps in the project, we will encounter some scenarios that require customization, and the existing collectors cannot meet our needs. At this time, we can also implement the Collector ourselves. The interface meets the requirements.

Collector interface detailed explanation

If you want to customize your own Collector, you must first understand what methods the Collector interface has that we need to implement, as well as the functions and uses of each method.

When we create a new CustomCollector class and declare to implement the Collector interface, we will find that we need to implement 5 methods:

The meanings of these five interfaces are summarized as follows:

Regarding the optional values of Characteristics, please see the interface description, as follows:

Now that we know the meanings and uses of these five interfaces, how do these interfaces work together? We can take a look at the implementation source code of the collector Collectors.toList():

public final class Collectors {

    static final Set CH_ID
            = Collections.unmodifiableSet(EnumSet.of(Collector.Characteristics.IDENTITY_FINISH));

public static 
    Collector> toList() {
        return new CollectorImpl<>((Supplier>) ArrayList::new, List::add,
                                   (left, right) -> { left.addAll(right); return left; },
                                   CH_ID);
    }
}

The CollectorImpl returned by the toList() method implements Collector and receives four parameters here. Let’s take a look at them in turn:

supplier：ArrayList::new,that is, an ArrayList is created as the result storage container。
accumulator：List::add, that is, for each element in the stream, the list.add() method is called to add it to the result container.
combiner：(left, right) -> { left.addAll(right); return left; }，the various sub-ArrayList results generated by parallel operations are merged into the final result through the list.addAll() method.
characteristics: You can see that CH_ID is used, which only contains Characteristics.IDENTITY_FINISH, that is, the final result is returned directly without secondary processing by the finisher method. Note that CONCURRENT is not declared here, because ArrayList is a non-thread-safe container, so this collector does not support use in concurrent processes.

In fact, CollectorImpl has two constructors. The constructor that accepts four parameters above will still call the constructor that receives five parameters, that is, it also needs to pass in finisher, but there is no need to process the result twice, so castingIdentity() is passed in by default, which returns itself.

Finally, we use a picture to illustrate the process of processing data with several methods:

Of course, if our Collector supports use in parallel streams, the processing process will be slightly different:

CustomCollector specific implementation

We have already understood the main methods in the Collector interface, now let us start implementing our own Collector!

Now suppose we have such a statistical requirement:

Calculate the student’s performance level. When the student’s score is greater than or equal to 90 points, 3 points will be scored. If the student score is greater than or equal to 80 points, 2 points will be scored. If the student score is greater than or equal to 60 points, 1 point will be scored. Otherwise, 0 points will be scored.

Next, let’s customize a collector to implement this function.

1.supplier

The purpose of the supplier method is to create a container where the results are stored and accumulated. Since we want to calculate the statistical results of multiple values, we must first declare an int result = 0 to store the accumulated results. However, in order for our Collector to support use in concurrent mode, we can use thread-safe AtomicInteger to implement it.

@Override
public Supplier supplier() {
    // Responsible for the gradual collection of the final result,
    // here return new AtomicInteger(0), subsequent accumulation on the basis of this
    return () -> new AtomicInteger(0);
}

2.accumulator

The accumulator method implements specific calculation logic and is also the core method in the entire Collector. The accumulator method will process the elements entering the Collector one by one:

@Override
public BiConsumer accumulator() {
    // The processing strategy after each element enters
    return (result, current) -> {
        int intValue = mapper.applyAsInt(current);
        if (intValue >= 90) {
            result.addAndGet(3);
        } else if (intValue >= 80) {
            result.addAndGet(2);
        } else if (intValue >= 60) {
            result.addAndGet(1);
        }
    };
}

Here is a supplementary explanation. Among the several methods of Collector, only accumulator needs to be executed repeatedly. It will be executed as many times as there are elements. The other methods will not directly deal with the elements in the Stream.

3.combiner

Because the thread-safe AtomicInteger is used as the result container in the previous supplier method, it supports use in parallel streams. According to the above introduction, parallel streaming is to divide the Stream into multiple fragments, and then calculate and process the fragments separately to obtain the results of each fragment. Finally, the results of these fragments need to be merged into the same total result. How to merge this , which is what we need to implement here:

@Override
public BinaryOperator combiner() {
    // Handling of multiple segmented results, direct summation
    return (result1, result2) -> {
        result1.addAndGet(result2.get());
        return result1;
    };
}

4.finisher

The target result of our Collector is to output an accumulated Integer value, but in order to ensure thread safety in concurrent streams, we use AtomicInteger as the result container. That is to say, in the end we need to convert the internal AtomicInteger object into an Integer object, so our implementation logic of the finisher method is as follows:

@Override
public Function finisher() {
    return AtomicInteger::get;
}

5.characteristics

Look at what features we need for our Collector:

Because we are implementing a Collector that allows for use in parallel streams, the CONCURRENT property needs to be declared;
As a statistical operation, there is no requirement for the order of calculation of elements, so we also declare the UNORDERED attribute at the same time;
Because our finisher method is doing a result processing transformation operation, not returning itself, the IDENTITY_FINISH attribute cannot be declared here.

@Override
public Set characteristics() {
    Set characteristics = new HashSet<>();
    characteristics.add(Characteristics.CONCURRENT);
    characteristics.add(Characteristics.UNORDERED);
    // characteristics.add(Characteristics.IDENTITY_FINISH);
    return characteristics;
}

Finally, we use our custom Collector for testing. Before that, we need to add an Integer type attribute score to the previous Student class and initialize a batch of students.

public static void main(String[] args) {
    List allStudents = Lists.newArrayList(
            new Student(”Computer”, “Bob”, 18, “male”, 59),
            new Student(”Computer”, “Ted”, 17, “male”, 60),
            new Student(”Economics”, “Zeka”, 19, “male”, 70),
            new Student(”Economics”, “Alan”, 19, “male”, 90),
            new Student( “Computer”, “Anne”, 21, “female”, 80),
            new Student(”Physics”, “Davis”, 21, “female”, 99)
    );
  
    System.out.println(”Serial processing results: “ + getScoreByCollect(allStudents));
    System.out.println(”Parallel processing results: “ + getScoreByParallelCollect(allStudents));
}

public static Integer getScoreByCollect(List allStudents) {
    return allStudents.stream().collect(new CustomCollector(Student::getScore));
}

public static Integer getScoreByParallelCollect(List allStudents) {
    return allStudents.stream().collect(new CustomCollector(Student::getScore));
}

Output:

Serial processing results: 10
Parallel processing results: 10

It can be seen that the results of serial and parallel processing are consistent. Interested readers can also create more students for testing and will find that parallel processing is faster than serial processing.

Summary

This article provides an in-depth analysis of the use of the collect method. Among them, I personally think that the most useful thing is its grouping function, which can greatly simplify the amount of our code. Is it like writing a requirements document? I don’t know if you have mastered its usage after reading the article. If you have any questions, please feel free to share them in the comment area.

Source code address

Github: https://github.com/junfeng0828/JavaBasic

Directory: src/main/java/stream/CollectCase.java

Share Java, SpringBoot & AI Development: Coding Skills & Interview

One Article to Master Java Streams🔥

Dylan Smith — Sat, 01 Aug 2026 02:16:44 GMT

Subscribe now

In the previous article, Lambda expression in java, I briefly mentioned the use of Stream. In this article, we will explore it in depth. First, let’s take the familiar Student class as an example. Suppose there are a group of students:

@Getter
@AllArgsConstructor
public static class Student {
    private String name;
    private Integer age;
}

List students = Lists.newArrayList(
    new Student(”Bob”, 18),
    new Student(”Ted”, 17),
    new Student(”Zeka”, 19));

Now there is such a demand:

Return students 18 and older from a given student list, in descending order of age, up to 2.

In Java7 and earlier code, we will implement it in the following way:

public List getTwoOldestStudents(List students) {
    List result = new ArrayList<>();
    // 1.Loop to determine the age of students, first filter out students who match the age
    for (Student student : students) {
      if (student.getAge() >= 18) {
        result.add(student);
      }
    }

    // 2.Sort the list of eligible students by age
    result.sort((s1, s2) -> s2.getAge() - s1.getAge());
    // 3.Determine the result size. If it is greater than 2, intercept the sublist of the first two data and return it.
    if (result.size() > 2) {
      result = result.subList(0, 2);
    }
    return result;
}

In Java8 and later versions, with the help of Stream, we can write the following code more elegantly:

public List getTwoOldestStudentsByStream(List students) {
        return students.stream()
                .filter(s -> s.getAge() >= 18)
                .sorted((s1, s2) -> s2.getAge() - s1.getAge())
                .limit(2)
                .collect(Collectors.toList());
    }

Differences between the two implementations:

From a functional perspective, procedural code implementation couples collection elements, loop iterations, and various logical judgments, exposing too many details. As requirements change and become more complex in the future, procedural code will become difficult to understand and maintain.

Functional solutions decouple code details and business logic. Similar to SQL statements, they express “what to do” rather than “how to do it”, allowing programmers to focus more on business logic and write more Clean, easy to understand and maintain code.

Based on my daily project practical experience, I have made a detailed summary of the core points, confusing usage, typical usage scenarios, etc. of Stream. I hope it can help everyone have a more comprehensive understanding of Stream and apply it to project development more efficiently.

First introduction to Stream

Java 8 adds the Stream feature, which enables users to manipulate data structures such as List and Collection in a functional and simpler way, and implements parallel computing without user awareness.

In a nutshell，to perform a computation, stream operations are composed into a stream pipeline. The Stream pipeline consists of the following three parts：

Create Stream (Create from source data, which may be an array, a collection, a generator function, an I/O channel, etc)；
Intermediate Operations (There may be zero or more, which transform a stream into another stream, such as filter(Predicate) )
Terminal Operation (which produces a result or side-effect, such as count() or forEach(Consumer))

The following diagram illustrates these processes:

Each Stream pipeline operation type contains several API methods. Let’s first list the functions of each API method.

1. Start the pipeline

Mainly responsible for directly creating a new Stream, or creating a new Stream based on existing array, List, Set, Map and other collection type objects.

In addition to Stream, which is a stream of object references, there are primitive specializations for IntStream, LongStream, and DoubleStream, all of which are referred to as “streams” and conform to the characteristics and restrictions described here.

2.Intermediate pipeline

This step is responsible for processing the Stream and returning a new Stream object. Intermediate pipeline operations can be superimposed.

3.Terminate pipeline

As the name implies, after terminating the pipeline operation, the Stream will end, and finally it may perform some logical processing, or return some execution result data as required.

Stream API Detailed Usage

1.Create Stream

//Stream.of, IntStream.of...
Stream nameStream = Stream.of(”Bob”, “Ted”, “Zeka”);
IntStream ageStream = IntStream.of(18, 17, 19);

//stream, parallelStream
Stream studentStream = students.stream();
        Stream studentParallelStream = students.parallelStream();

In most cases, we create a Stream based on an existing collection list.

2.Intermediate Operations

2.1 map

Both map and flatMap are used to convert existing elements to other element types. The difference is:

map must be one-to-one, that is, each element can only be converted into a new element
flatMap can be one-to-many, that is, each element can be converted into one or more new elements

Let’s look at the map method first. The current requirements are as follows:

Convert the previous list of student objects to a list of student names and output:

/**
     * Use of map: one-to-one   
     * @param students
     * @return
     */
    public List objectToString(List students) {
        return students.stream()
                .map(Student::getName)
                .collect(Collectors.toList());
    }

Output：

[Bob, Ted, Zeka]

As you can see, there are three Students in the input, and there will be three Student names in the output.

2.2 flatMap

Now let’s expand the requirements.

The school requires every student to join a team. Suppose Bob, Ted, and Zeka join the basketball team. Alan, Anne, and Davis join the football team.

@Getter
@AllArgsConstructor
public static class Team {
    private String type;
    private List students;
}

List basketballStudents = Lists.newArrayList(
                new Student(”Bob”, 18),
                new Student(”Ted”, 17),
                new Student(”Zeka”, 19));

List footballStudent = Lists.newArrayList(
                new Student(”Alan”, 19),
                new Student(”Anne”, 21),
                new Student(”Davis”, 21));

Team basketballTeam = new Team(”bastetball”, basketballStudents);
Team footballTeam = new Team(”football”, footballStudent);
List teams = Lists.newArrayList(basketballTeam, footballTeam);    //Lists Object depends on the com.google.common.collect

Now we need to count the students in all teams and return them in a merged list. How would you implement this requirement?

We try to use the map method to achieve it, as follows:

List> allStudents = teams.stream()
    .map(Team::getStudents)
    .collect(Collectors.toList());

We can see that if it is unsuccessful, the returned result type is List>, and what we want is actually List.

However, we can easily solve this problem in Java7 and previous versions, as follows:

List allStudents = new ArrayList<>();
for (Team team : teams) {
    for (Student student : team.getStudents()) {
      allStudents.add(student);
    }
}

But this code with two nested for loops is not elegant. Faced with this demand, flatMap can come into play.

List allStudents = teams.stream()
    .flatMap(t -> t.getStudents().stream())
    .collect(Collectors.toList());

Do you think it’s cool? It’s done in one line of code. The flatMap method accepts a lambda expression function. The return value of the function must be a stream type. The flatMap method will eventually merge all the returned streams to generate a new Stream, but the map method cannot do this.

The following diagram clearly illustrates the processing logic of flatMap:

2.3 filter, distinct, sorted, limit

These are commonly used Stream intermediate operation methods. They are often used together. For specific function descriptions, you can see the previous table. Let’s look directly at the requirements this time:

Regarding the list of students in all teams just now, we now need to know the ages of the second and third oldest among these students. They need to be at least 18 years old. In addition, if there are duplicates, they can only be counted as one.

List topTwoAges = allStudents.stream() /
      .map(Student::getAge) //[18, 17, 19, 19, 21, 21]
      .filter(a -> a >= 18) //[18, 19, 19, 21, 21]
      .distinct()   //[18, 19, 21]
      .sorted((a1, a2) -> a2 - a1)  //
      .skip(1)  //[19, 18]
      .limit(2) //[19, 18]
      .collect(Collectors.toList());
    
System.out.println(topTwoAges);

Output：

[19, 18]

Note：Since there are only two elements left after the skip method operation, the limit step can actually be omitted.

I believe you can clearly understand the functions of these methods without much explanation. It is highly recommended that you take the initiative to code and try it yourself!

2.4 peek, foreach

Both the peek method and the foreach method can be used to traverse elements and process them one by one, so we will put them together for comparison and explanation. But it is worth noting that peek is an intermediate operation method and foreach is a terminal operation method.

As described before, the intermediate operation can only be used as a processing step in the middle of the Stream pipeline. It cannot be executed directly to get the result. It must be executed later with the cooperation of a terminal operation. As a terminal method with no return value, foreach can perform the corresponding operation directly.

For example, we say hello, xxx… to each student on the basketball team using peek and foreach respectively.

//peak
System.out.println(”------start peek------”);
basketballTeam.getStudents().stream().peek(s -> System.out.println(”Hello, “ + s.getName()));
System.out.println(”------end peek------”);

System.out.println();
//foreach
System.out.println(”------start foreach------”);
basketballTeam.getStudents().stream().forEach(s -> System.out.println(”Hello, “ + s.getName()));
System.out.println(”------end foreach------”);

As can be seen from the output, peek is not executed when called alone, while foreach can be executed directly:

------start peek------
------end peek------

------start foreach------
Hello, Bob
Hello, Ted
Hello, Zeka
------end foreach------

If you add a terminal operation after peek, it can be executed.

System.out.println(”------start peek------”);
basketballTeam.getStudents().stream().peek(s -> System.out.println(”Hello, “ + s.getName())).count();
System.out.println(”------end peek------”);

//output
------start peek------
Hello, Bob
Hello, Ted
Hello, Zeka
------end peek------

It is worth mentioning that peek should be used with caution to carry business processing logic.Think about it, as long as there is a termination method, will the peek method be executed?Uncertain! Look at the version, look at the scene!

For example, in the Java8 version, the peek method just now will be executed normally, but in Java17 it will be automatically optimized and the logic in the peek will not be executed.As for the reason, you can take a look at the JDK17 official API documentation.

Because for methods such as findFirst and count, the peek method will be regarded as an operation that is not related to the result, so it is directly optimized and not executed.

We can see from the comments of peek’s source code that the recommended usage scenario of peek is for some debugging scenarios. You can use peek to print out the information of each element to facilitate debugging and problem location analysis during the development process. Just like the name peek, it seems that it is just to peek at the changes in data during execution.

Subscribe now

3.Terminal Operation

Here we divide terminal operations into two categories.

One type is to obtain simple results, mainly including max, min, count, findAny, findFirst, anyMatch, allMatch and other methods; the so-called simple means that the result form is Numbers, Boolean values, or Optional object values, etc.

The other type is the result collection type. Most scenarios are to obtain the result object of a collection class, such as List, Set or HashMap, etc., which are mainly implemented by the collect method.

3.1 Simple result types

（1）max, min

max() and min() are mainly used to return the maximum/minimum value of the element after stream processing. The return result is packaged by Optional. For the use of Optional, please refer to the previous article, Lambda combined with Optional makes Java’s handling of null more elegant.

Let’s look directly at the example

Tell me who are the oldest and youngest on the football team?

//max
footballTeam.getStudents().stream()
    .map(Student::getAge)
    .max(Comparator.comparing(a -> a))
    .ifPresent(a -> System.out.println(”The maximum age for a football team is “ + a));

//min
footballTeam.getStudents().stream()
    .map(Student::getAge)
    .min(Comparator.comparing(a -> a))
    .ifPresent(a -> System.out.println(”The minimum age for a football team is “ + a));

Output:

The maximum age for a football team is 21
The minimum age for a football team is 19

（2）findAny, findFirst

findAny(), findFirst() are mainly used to terminate stream processing when an element that meets the conditions is found. findAny() is the same as findFirst for serial Stream and more efficient for parallel Stream.

Assume that the basketball team has a new student, Tom, who is 19 years old.

List basketballStudents = Lists.newArrayList(
                new Student(”Bob”, 18),
                new Student(”Ted”, 17),
                new Student(”Zeka”, 19),
	        new Student(”Tom”, 19));

Take a look at the results of the following two requirements

Return the name of the first student on the basketball team whose age is 19;
Return the name of any student on the basketball team who is 19 years old;

//findFirst
basketballStudents.stream()
    .filter(s -> s.getAge() == 19)
    .findFirst()
    .map(Student::getName)
    .ifPresent(name -> System.out.println(”findFirst: “ + name));

//findAny
basketballStudents.stream()
    .filter(s -> s.getAge() == 19)
    .findAny()
    .map(Student::getName)
    .ifPresent(name -> System.out.println(”findAny: “ + name));

Output：

findFirst: Zeka
findAny: Zeka

It can be seen that there is no difference between the two functions under serial Stream.The differences in parallel processing will be introduced later.

（3）count

Since a new student has been added to the basketball team, how many students are there in the basketball team now?

System.out.println(”The number of students on the basketball team: “ + basketballStudents.stream().count());

Output:

The number of students on the basketball team: 4

（4）anyMatch, allMatch, noneMatch

As the names suggest, these three methods are used to determine whether the element meets the conditions and return a boolean value. Look at the following three examples

Is there a student named Alan on the football team?
Are all students on the football team under 22 years old?
Are there no students on the football team who are over 20 years old?

//anymatch
System.out.println(”anymatch: “
                   + footballStudent.stream().anyMatch(s -> s.getName().equals(”Alan”)));

//allmatch
System.out.println(”allmatch: “
                   + footballStudent.stream().allMatch(s -> s.getAge() < 22));//nonematch
System.out.println(”noneMatch: “
                   + footballStudent.stream().noneMatch(s -> s.getAge() > 20));

Output:

anymatch: true
allmatch: true
noneMatch: false

3.2 Result collection types

（1）Generate a collection

Generating collections should be considered the most commonly used scenario of collect. In addition to the List mentioned before, Sets, Maps, etc. can also be produced, as follows:

//Get the latest student age distribution for the basketball team, no duplicates allowed
Set ageSet = basketballStudents.stream().map(Student::getAge).collect(Collectors.toSet());
System.out.println(”set: “ + ageSet);

//Get a map of the names and ages of all students on the basketball team
Map nameAndAgeMap = basketballStudents.stream().collect(Collectors.toMap(Student::getName, Student::getAge));
System.out.println(”map: “ + nameAndAgeMap);

Output:

set: [17, 18, 19]
map: {Ted=17, Tom=19, Bob=18, Zeka=19}

(2) Generate concatenated strings

In addition to generating collections, collect can also be used to concatenate strings.

For example, after we get the names of all students on the basketball team, we hope to use “,” to splice all the names and return a String.

System.out.println(basketballStudents.stream().map(Student::getName).collect(Collectors.joining(”,”)));

Output:

Bob,Ted,Zeka,Tom

Maybe you will say, can’t you use String.join() to achieve this function? There is no need to use stream to achieve this. It should be stated here that the charm of Stream is that it can be combined with other business logic for processing, making the code logic more natural and coherent. If it is purely a request for String string splicing, there is really no need to use Stream to achieve it. After all, there is no need to kill a chicken with a big knife!

In addition, Collectors.joining() also supports defining prefixes and suffixes, which is more powerful.

System.out.println(basketballStudents.stream().map(Student::getName).collect(Collectors.joining(”,”, “(”,”)”)));

Output:

(Bob,Ted,Zeka)

(3) Generate statistical results

There is another scenario that may be rarely used in practice, which is to use collect to generate the sum of digital data. Let’s take a brief look at it.

//Calculate average
System.out.println(”average age: “
                + basketballStudents.stream().map(Student::getAge).collect(Collectors.averagingInt(a -> a)));、

//Summary statistics
IntSummaryStatistics summary = basketballStudents.stream()
    .map(Student::getAge)
    .collect(Collectors.summarizingInt(a -> a));
System.out.println(”summary: “ + summary);

In the above example, using collect to perform some mathematical operations on age, the results are as follows:

average age: 18.0
summary: IntSummaryStatistics{count=3, sum=54, min=17, average=18.000000, max=19}

Parallel Stream

Mechanism description

Using parallel streams can effectively utilize computer performance and improve logic execution speed. Parallel Stream divides an entire stream into multiple fragments, then executes processing logic on each fragmented stream in parallel, and finally summarizes the execution results of each fragmented stream into an entire Stream.

As shown in the diagram below, filter for numbers greater than or equal to 18:

Use findAny() efficiently

As mentioned before, findAny() is more efficient in Parallel Stream, and it can be seen from the API documentation that the results of each execution of this method may be different.

We try to execute findAny() 10 times using parallelStream to find any student name that satisfies the criteria of Bob, Tom, and Zeka.

for (int i = 0; i < 10; i++) {
    basketballStudents.parallelStream()
        .filter(s -> s.getAge() >= 18)
        .findAny()
        .map(Student::getName)
        .ifPresent(name -> System.out.println(”findAny in parallel stream: “ + name));
}

Output:

findAny in parallel stream: Zeka
findAny in parallel stream: Zeka
findAny in parallel stream: Tom
findAny in parallel stream: Zeka
findAny in parallel stream: Zeka
findAny in parallel stream: Bob
findAny in parallel stream: Zeka
findAny in parallel stream: Zeka
findAny in parallel stream: Zeka
findAny in parallel stream: Zeka

This output confirms the instability of findAny().

For more information about Parallel Stream, I will further analyze and discuss it in a later article.

Additional information

1. Delayed execution

Streams are lazy; calculations on source data are only performed when a terminal operation is initiated, and source elements are consumed only when needed. For example, the peek method mentioned before in the article is a good example.

2. Avoid performing terminal operations twice

It is necessary to add a reminder here. Once a Stream is terminated, it cannot be used to perform other operations later, otherwise an error will be reported. See the following example:

Stream studentStream = basketballStudents.stream().filter(s -> s.getAge() == 19);
// Calculate the number of students
System.out.println(”the number of students: “ + studentStream.count());
// If you try it again, an error will be reported
try {
    System.out.println(”the number of students: “ + studentStream.count());
} catch (Exception e) {
    e.printStackTrace();
}

Output:

the number of students: 2
java.lang.IllegalStateException: stream has already been operated upon or closed
			at java.util.stream.AbstractPipeline.(AbstractPipeline.java:203)
			...

Summarize

This article introduces how to use Stream to write more elegant code through multiple cases, and briefly introduces the actual role of each API. Due to space limitations, this article only briefly introduces the usage of collect and Parallel Stream. I will discuss them in depth in subsequent articles.

In addition, if you want to master Stream, it is not enough to look at it, but also need to practice in the project. If you have any questions, please feel free to discuss them in the comments section!

Source code address

Github: https://github.com/junfeng0828/JavaBasic

Directory: src/main/java/stream/StreamCase.java

Share Java, SpringBoot & AI Development: Coding Skills & Interview

Java: The Clearest Lambda Explanation You’ll Ever See

Dylan Smith — Fri, 31 Jul 2026 13:23:05 GMT

1.What is Lambda?

We know that for a Java variable, we can assign a “value” to it, and you can do something with it.

Integer a = 1;
String s = “Hello”;
System.out.println(s + a);

What should you do if you want to assign a “piece of code” to a Java variable?

For example, I want to assign the block of code on the right to a Java variable called codeBlock:

Before Java 8, this was not possible. But after the advent of Java 8, it can be done using the Lambda feature. The intuitive expression is as follows：

codeBlock = public void doSomething(String s) {
        System.out.println(s);
}

Of course, this is not a very concise way of writing. So, in order to make this assignment operation more elegant, we can remove some useless declarations.

Subscribe now

In this way, we have successfully assigned a “piece of code” to a variable very elegantly. And “this piece of code”, or “this function assigned to a variable”, is a Lambda expression.

But there is still a question here, that is, what type should the variable codeBlock be?

In Java 8, all Lambda types are an interface, and the Lambda expression itself, that is, the “piece of code”, needs to be an implementation of this interface. This is one of the keys to understanding Lambda in my opinion. In short, the Lambda expression itself is the implementation of an interface. It might still be a bit confusing to say this directly, so let’s continue with examples. We add a type to codeBlock above:

This type of interface that has only one function to be implemented is called a “functional interface”.

In order to prevent later people from adding interface functions to this interface, which will cause multiple interface functions to be implemented and become a “non-functional interface”, we can add a declaration @FunctionalInterface to this interface, so that others cannot add new functions to it.

In this way, we get a complete Lambda expression declaration.

2.What is The Function of Lambda Expression?

The most intuitive effect is to make the code extremely concise.

We can compare Lambda expressions and traditional Java implementations of the same interface:

These two ways of writing are essentially equivalent. But obviously, the way of writing in Java 8 is more elegant and concise. Moreover, since Lambda can be directly assigned to variables, we can directly pass Lambda as a parameter to the function, while traditional Java must have clear interface implementation and initialization definition:

In some cases, this interface implementation only needs to be used once. Traditional Java 7 requires you to define a “polluting environment” interface to implement InterfaceImpl. In comparison, Java 8’s Lambda appears much cleaner.

Lambda combines FunctionalInterface Lib, forEach, stream(), method reference and other new features to make the code more concise!

Let’s go directly to the example.

Assume that the definition of Student and the value of List(Student) are given.

@Getter
@AllArgsConstructor
public static class Student {
  private String name;
  private Integer age;
}

List students = Arrays.asList(
  new Student(”Bob”, 18),
  new Student(”Ted”, 17),
  new Student(”Zeka”, 18));

Now you need to print out the names of all 18-year-old students in students.

Original Lambda writing method: define two functional interfaces, define a static function, call the static function and assign Lambda expressions to the parameters.

@FunctionalInterfaceinterface AgeMatcher {
  boolean match(Student student);
}

@FunctionalInterface
interface Executor {
  boolean execute(Student student);
}

public static void matchAndExecute(List students, AgeMatcher matcher, Executor executor) {
  for (Student student : students) {
    if (matcher.match(student)) {
      executor.execute(student);
    }
  }
}

public static void main(String[] args) {

        List students = Arrays.asList(
                new Student(”Bob”, 18),
                new Student(”Ted”, 17),
                new Student(”Zeka”, 18));

        matchAndExecute(students, 
                        s -> s.getAge() == 18, 
                        s -> System.out.println(s.getName()));
}

This code is actually relatively concise, but can we be more concise?

Of course, there is a functional interface package in Java 8, which defines a large number of functional interfaces that may be used (java.util.function (Java Platform SE 8)).

Therefore, we don’t need to define the two functional interfaces AgeMatcher and Executor here at all. We can just use Predicate(T) and Consumer(T) in the Java 8 functional interface package because of their pair of interfaces. The definition is actually the same as AgeMatcher/Executor.

Step 1: Simplify — Utilize functional interface packages:

public static void matchAndExecute(List students, Predicate predicate, Consumer consumer) {
        for (Student student : students) {
            if (predicate.test(student)) {
                consumer.accept(student);
            }
        }
    }

The for each loop in matchAndExecute is actually very annoying. Here you can use Iterable’s own forEach() instead. forEach() itself can accept a Consumer(T) parameter.

Step 2: Simplify — Replace the foreach loop with Iterable.forEach() :

public static void matchAndExecute(List students, Predicate predicate, Consumer consumer) {
        students.forEach(s -> {
            if (predicate.test(s)) {
                consumer.accept(s);
            }
        });
    }

Since matchAndExecute is actually just an operation on the List, here we can get rid of matchAndExecute and directly use the stream() feature to complete it. Several methods of stream() accept parameters such as Predicate(T) and Consumer(T) (java.util.stream (Java Platform SE 8)). Once you understand the above content, stream() is very easy to understand and does not require any further explanation.

Step 3: Simplify — use stream() instead of static functions:

students.stream()
        .filter(s -> s.getAge() == 18)
        .forEach(s -> System.out.println(s.getName()));

Compared with the original Lambda writing method, this is very concise. But if we ask for a change to print all the information of the student, and s -> System.out.println(s); then we can use Method reference to continue simplification. The so-called Method reference is to replace the Lambda expression with the method of other Object/Class that has been written. The format is as follows:

Step 4: Simplify — You can use Method reference instead of the Lambda expression in forEach:

students.stream()
	.filter(s -> s.getAge() == 18)
        .map(Student::getName)
	.forEach(System.out::println);

This is basically the most concise version I can write.

There is still something to discuss and learn about Lambda in Java. For example, how to use the characteristics of Lambda to perform parallel processing, etc.

In short, I am just giving you a general introduction to give you an idea. There are many related tutorials about Lambda on the Internet, read more and practice more. As time goes by, there will definitely be improvements.

Share Java, SpringBoot & AI Development: Coding Skills & Interview