Forem: Vahram Papazyan

Modern Java Features: Part 2 - From Java 22 to 25

Vahram Papazyan — Tue, 23 Dec 2025 16:57:58 +0000

Welcome back to our series exploring the latest innovations in Java! In Part 1, we covered foundational features like pattern matching and records. Now we turn our attention to features that dramatically improve developer experience and application performance.

This installment covers five game-changing additions to modern Java:

Compact Source Files & Instance Main Methods — Write Java programs without boilerplate, making the language more accessible to beginners and perfect for scripting
Primitive Types in Patterns — Extend Java's pattern matching capabilities to work seamlessly with primitive types
Scoped Values — A modern, efficient alternative to ThreadLocal for passing context in concurrent applications
ZGC — A production-ready garbage collector that keeps pause times under 1ms, even with massive heaps
AOT Class Loading — Dramatically reduce startup times by caching class loading work

Whether you're building microservices that need instant startup, teaching Java to newcomers, or running latency-sensitive applications, these features offer practical solutions to real-world challenges.

Let's dive in.

Compact Source Files & Instance Main Methods

✅ Key JEPs

JEP 445: Unnamed Classes and Instance Main Methods (Preview, Java 21)
JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview, Java 22)
JEP 477: Implicitly Declared Classes and Instance Main Methods (Third Preview, Java 23)
JEP 495: Simple Source Files and Instance Main Methods (Fourth Preview, Java 24)
JEP 512: Compact Source Files and Instance Main Methods (Final, Java 25)

🔍 What’s New

JEP 512 finalizes features that simplify writing small Java programs by removing boilerplate and allowing more natural entry points. It combines two ideas:

Compact source files — Java files that omit explicit class declarations.

Methods and fields can appear directly at the top level.
The compiler implicitly wraps them in a generated class.
All public types from the java.base module are automatically imported.

Instance main methods — Java can now start programs from instance methods (like void main() or void main(String[] args)), not only from public static void main(...).

The launcher instantiates the implicit class and calls the method automatically.

A new helper class, java.lang.IO, provides simple console I/O utilities such as IO.println() and IO.readln().

void main() {
    IO.println("Hello, world!");
}

This code compiles and runs directly — no class, no static, no public.

💡 Why It matters

Makes Java friendlier for beginners and small scripts.
Reduces boilerplate for quick demos, exercises, or tools.
Preserves full compatibility: compact source files are still standard .java files.

⚠️ Considerations

Compact files can’t define package statements or named classes.
These files must have exactly one top-level declared class.
IO methods are not implicitly imported; you must qualify them as IO.println() or use import static IO.*.
IDE and build tool support may vary during early adoption.

Primitive types in patterns, `instanceof`, and `switch`

✅ Key JEPs

JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview, Java 23)
JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview, Java 24)
JEP 507: Primitive Types in Patterns, instanceof, and switch (Third Preview, Java 25)

🔍 What’s new

This JEP expands the pattern-matching, instanceof, and switch capabilities of Java to primitive types (such as int, long, double, boolean) — not only reference types. Key changes include:

Allowing primitive type patterns in both nested and top-level pattern contexts, e.g., x instanceof int i or case int i in switch.
Extending instanceof so that it can test a value for conversion to a primitive type safely: e.g., if (i instanceof byte b) { … } means “if i can safely convert to byte without loss”.
Extending switch so that the selector and case labels may be any primitive type, and case patterns can bind primitives: e.g.,

  switch (v) {
    case int i -> System.out.println("int value: " + i);
    case double d -> System.out.println("double value: " + d);
  }

Aligning pattern matching uniformly across types: whether reference or primitive, you can decompose and test with patterns.

💡 Why it matters

Improves uniformity and expressiveness: Previously Java’s pattern matching, instanceof, and switch were limited or uneven when it came to primitives versus reference types. Now primitives join the party.
Reduces boilerplate and error-prone code for primitive conversions and range checking: For example, the old pattern:

  int i = …;
  if (i >= Byte.MIN_VALUE && i <= Byte.MAX_VALUE) {
    byte b = (byte) i;
    …
  }

This can now become:

  if (i instanceof byte b) {
    …
  }

Enhances switch flexibility: You can switch on long, float, double, boolean, etc., and use pattern guards and binding for primitives, making certain control-flow clearer and more powerful.

⚠️ Considerations

Preview feature: This capability is still under preview in Java 25, meaning the specification is finalized for now but may still change and requires --enable-preview.
Safety & conversions: The feature does not introduce new implicit conversions that lose information. Patterns only match when the conversion is safe (i.e., no information loss). Developers still need to understand when a primitive value can fit into a target type.
Tooling / backwards compatibility: Because this is preview, IDE support, build tool integration, and migration for large codebases may lag or require extra configuration.
Readability for teams: While this adds expressive power, over-use in contexts not suited to pattern matching (especially primitives) might reduce clarity for developers used to more explicit code.

This feature brings Java's type system and pattern matching into better alignment, making primitive types first-class citizens in modern control flow constructs.

Scoped Values (Preview)

✅ Key JEPs

JEP 446: Scoped Values (Preview, Java 21)
JEP 464: Scoped Values (Second Preview, Java 22)
JEP 481: Scoped Values (Third Preview, Java 23)
JEP 487: Scoped Values (Fourth Preview, Java 24)
JEP 506: Scoped Values (Final, Java 25)

🔍 What’s new

The JEP introduces the concept of scoped values — immutable values that can be bound to a thread (and its descendant tasks) for a well-defined lifetime, allowing code deep in a call chain to access context without explicitly passing parameters.
Key characteristics:

A scoped value is created via ScopedValue.newInstance() and bound for execution via something like ScopedValue.where(USER, value).run(…).
Inside that dynamic scope, any method — even far down the stack or running in a child thread (via structured concurrency) — can call V.get() and retrieve the bound value.
The binding has a bounded lifetime: once run(...) completes, the binding ends and V.get() becomes invalid (or must be checked).
Scoped values are preferred over ThreadLocal for many use-cases: they require immutable data, allow sharing across virtual threads efficiently, and trace the lifetime of the binding in the code structure.

Code sample:

static final ScopedValue<String> USER = ScopedValue.newInstance();

void handleRequest(Request req) {
    String userId = /* extract user id from req */;
    ScopedValue.where(USER, userId)
               .run(() -> processRequest(req));
}

void processRequest(Request req) {
    System.out.println("Current user: " + USER.get());
    // deeper calls can also see USER.get() without passing userId explicitly
}

💡 Why it matters

Cleaner argument passing: Instead of threading contextual data (like user IDs, request-context, tracing IDs) through many method parameters, scoped values let you bind once and let nested methods access when needed.
Better suitability for many threads (including virtual threads): Because the data is immutable and the lifetime is bounded, there’s far less memory overhead versus thread-locals in large-scale concurrent systems.
Improved reasoning: The dynamic scope is explicit in the code (via the where().run() structure), so it’s easier to understand when the data is valid, and when it is not. This contrasts with thread-locals that may leak or remain bound beyond desired lifetimes.

⚠️ Considerations

As a preview feature, the API or semantics may change in future releases.
Scoped values are immutable once bound; they are not a replacement for thread-locals in cases where you need mutable per-thread state or long-lived caching.
Code needs to ensure that get() is only called within a valid bound scope; outside that, an exception may be thrown (or isBound() should be checked).
Tooling, frameworks, and IDE support may lag since this is in preview; plus, migrating from existing thread-local heavy code will need careful design.
Scopes propagate to child threads only when using compatible concurrency constructs (such as via the preview structured concurrency features) — simple new Threads might not inherit the binding automatically unless explicitly supported.

ZGC: Low-latency garbage collector

✅ Key JEPs

JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental, Java 11)
JEP 351: ZGC: Uncommit Unused Memory (Experimental, Java 13)
JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production, Java 15)
JEP 439: Generational ZGC (Final, Java 21)
JEP 474: ZGC: Generational Mode by Default (Java 23)
JEP 490: ZGC: Remove the Non-Generational Mode (Java 24)

ZGC (Z Garbage Collector) is a low-latency, concurrent GC designed to keep pause times below 1 ms, regardless of heap size. It supports heaps from MBs to multi-terabyte ranges and is fully production-ready since JDK 15.

🔍 What it does

Performs most GC work concurrently with the application.
Uses colored pointers and load barriers to relocate objects without long stop-the-world pauses.
From JDK 21, supports Generational ZGC (JEP 439) for better throughput in allocation-heavy workloads.

Enable it via:

java -XX:+UseZGC -Xmx8g

💡 Why it matters

Ideal for latency-sensitive systems (finance, real-time analytics).
Scales efficiently to very large heaps.
Requires minimal tuning compared to older collectors.

⚠️ Considerations

Slightly higher memory overhead due to concurrent design.
Throughput may be a bit lower than G1 in CPU-bound tasks.

Ahead-of-time class loading & linking

✅ Key Jeps

JEP 483: Ahead-of-Time Class Loading & Linking (Final, Java 24)

🔍 What the JEP does

JEP 483 introduces a JVM feature that allows Java applications to load and link classes ahead of time, then store that state in a cache for later runs. The goal is to reduce startup time by shifting part of the class-loading work from runtime to a prior “training” phase.

Essentially:

You run your application once (a “training run”) to record which classes are loaded and linked.
You create an AOT cache (archive) containing that information.
On the next startup, the JVM reuses that cache, skipping much of the load/link process to start faster.

💡 Why it matters

Applications, especially large frameworks like Spring, spend noticeable time at startup loading and linking classes. By caching this work, the JVM can cut startup time dramatically—benchmarks show up to around 40% improvement in some cases.

Because this mechanism works without changing your code, it’s easy to adopt in existing projects. It also supports Java’s broader effort to improve startup and footprint, especially for cloud-native and serverless workloads.

⚙️ How it works (high Level)

JEP 483 makes it possible for Java to load and link classes ahead of time, caching that work for faster subsequent startups. It’s a simple yet powerful feature for improving startup performance in modern Java applications—particularly useful for microservices, short-lived workloads, and cloud deployments. Here is how it works (you need to have the jar file of your app with the Manifest file):

Training phase:

  java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar

This records which classes are loaded and linked.

Cache creation phase:

  java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar

This generates the AOT cache file app.aot.

Production run:

  java -XX:AOTCache=app.aot -cp app.jar

The JVM uses the cache to start up faster. If the cache isn’t valid, it gracefully falls back to normal startup.

⚠️ Considerations

The classpath and module configuration during the training phase must match those used later.
The optimization targets startup performance, not runtime throughput.
The training and caching workflow adds a bit of setup overhead, especially in containerized or CI/CD environments.

Conclusion

The features covered in this article reflect Java's commitment to staying relevant in a rapidly changing software landscape. From compact source files that make Java approachable for beginners and scripters, to ZGC delivering microsecond-level pause times for demanding production workloads—these aren't just incremental improvements. They represent fundamental shifts in how we can use Java.

Java continues to evolve rapidly, balancing its enterprise heritage with modern development needs. Whether you're building cloud-native microservices, teaching programming fundamentals, or optimizing high-frequency trading systems, these features provide concrete solutions to real problems.

Modern Java Evolution: Part 1 - From Java 22 to 25

Vahram Papazyan — Mon, 22 Dec 2025 09:10:02 +0000

Java has undergone a transformative evolution from versions 22 through 25, introducing features that significantly enhance readability, performance, native interop, and structured concurrency. This article breaks down key JEPs from recent releases, grouped by theme, and highlights both their benefits and potential considerations.

Flexible Constructor Bodies

✅ Key JEPs

JEP 447: Statements before super(...) (Preview, Java 22)
JEP 482: Flexible Constructor Bodies (Second Preview, Java 23)
JEP 492: Flexible Constructor Bodies (Third Preview, Java 24)

🔍 What’s New

Traditionally, Java required that the first line in a constructor must be a call to super(...). These JEPs progressively relax that restriction, allowing:

Preliminary statements (e.g., input validation, logging) before calling super(...).
Explicit control flow logic before initializing the superclass.

Here is what it looks like:

class Student extends Person {
    public Student(String name) {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("Name cannot be null or blank");
        }

        System.out.println("Validated name: " + name);

        super(name);
    }
}

💡 Why It Matters

This aligns Java with more intuitive OOP practices, particularly in constructors, where argument validation is often required. It enables safer, more flexible class hierarchies.

⚠️ Considerations

Developers must still ensure that fields are not accessed before full initialization, preserving constructor safety.

Foreign Function & Memory API

✅ Key JEPs

JEP 424: Foreign Function & Memory API (First Preview, Java 19)
JEP 454: Foreign Function & Memory API (Stable, Java 22)

🔍 What’s New

This API replaces JNI with a safer, more efficient, and idiomatic way to:

Call native (C/C++) libraries.
Allocate and manage memory off-heap using MemorySegment, MemoryLayout, and Linker.

try (Arena arena = Arena.ofConfined()) {
    MemorySegment segment = arena.allocate(100);
    // Use memory directly
}

The Foreign Function & Memory API (FFM API) defines classes and interfaces so that client code in
libraries and applications can:

Control the allocation and deallocation of foreign memory (MemorySegment, Arena, and SegmentAllocator),
Manipulate and access structured foreign memory (MemoryLayout and VarHandle), and
Call foreign functions (Linker, SymbolLookup, FunctionDescriptor, and MethodHandle). The FFM API resides in the java.lang.foreign package of the java.base module.

💡 Why It Matters

Java can now operate with native libraries without boilerplate JNI code. This is huge for performance-sensitive
applications like machine learning, image processing, and systems integration.

⚠️ Considerations

Still evolving, and requires an understanding of low-level memory and ABI (Application Binary Interface) details. Avoid misuse that could cause memory leaks or segmentation faults.

Unnamed Variables & Patterns

✅ Key JEPs

JEP 443: Unnamed Patterns and Variables (Preview, Java 21)
JEP 456: Unnamed Variables & Patterns (Final, Java 22)

🔍 What’s New

You can now use _ as a placeholder in places where a variable is syntactically
required, but the actual value is not used. Here is what this JEP adds:

An unnamed variable, declared by using an underscore character, _ (U+005F), to stand in for the name of the local variable in a local variable declaration statement, or an exception parameter in a catch clause, or a lambda parameter in a lambda expression.

try {
    // some risky code
} catch (IOException _) {
    System.out.println("I/O error occurred");
}

An unnamed pattern variable, declared by using an underscore character to stand in for the pattern variable in a type pattern.

if (obj instanceof String _) {
    System.out.println("It's a string, but we don't care about the value.");
}

An unnamed pattern, denoted by an underscore character, is equivalent to the unnamed type pattern var _. It allows both the type and name of a record component to be elided in pattern matching.

record Point(int x, int y) {}

Point p = new Point(3, 4);

if (p instanceof Point(_, int y)) {
    System.out.println("Matched, but ignored both fields.");
}

⚠️ Important: You cannot use _ more than once in the same pattern expression. For example, if (p instanceof Point(_, _)) is not allowed.

💡 Why It Matters

This is a small syntax change with big readability improvements, especially in exhaustive pattern matching or placeholder variables.

⚠️ Considerations

Overusing _ may make the code obscure. Use it where the intention is clear.

Stream Gatherers

✅ Key JEPs

JEP 461: Stream Gatherers (First Preview, Java 22)
JEP 473: Stream Gatherers (Second Preview, Java 23)
JEP 485: Stream Gatherers (Final, Java 24)

🔍 What’s New

Stream.gather() introduces a mechanism to support intermediate stream operation that processes the elements of a stream by applying a user-defined entity called a gatherer. With the gather operation, we can build efficient, parallel-ready streams that implement almost any intermediate operation. This gather method is to intermediate operations what Stream::collect(Collector) is to terminal operations.

An example of a built-in gatherer:

List<Integer> numbers = List.of(1, 2, 3, 4, 5, 6, 7);

List<List<Integer>> grouped = numbers.stream()
        .gather(windowFixed(3))
        .toList();

System.out.println(grouped);

You can also define a custom gatherer and use it.

💡 Why It Matters

This allows complex grouping, windowing, buffering, and merging logic to be cleanly expressed in the Stream API, e.g., batching or handling sliding windows, making stream pipelines more flexible and expressive.

⚠️ Considerations:
It adds complexity. Understanding Gatherer mechanics (accumulator, finisher) takes practice.

Structured Concurrency

✅ Key JEPs

JEP 453: Structured Concurrency (First Preview, Java 21)
JEP 462: Structured Concurrency (Second Preview, Java 22)
JEP 480: Structured Concurrency (Third Preview, Java 23)
JEP 499: Structured Concurrency (Fourth Preview, Java 24)
JEP 505: Structured Concurrency (Fifth Preview, Java 25)

🔍 What’s New

Structured concurrency is an approach to concurrent programming that preserves the natural relationship between tasks and subtasks, which leads to more readable, maintainable, and reliable concurrent code. It treats concurrent tasks as a structured unit of work—bound together by lifecycle and failure policies. It introduces APIs like StructuredTaskScope.

Structured concurrency derives from a simple principle: If a task splits into concurrent subtasks then they all return to the same place, namely the task's code block.

Response handle() throws InterruptedException {
    try (var scope = StructuredTaskScope.open()) {
        Subtask<String> user = scope.fork(() -> findUser());
        Subtask<Integer> order = scope.fork(() -> fetchOrder());

        scope.join();   // Join subtasks, propagating exceptions

        // Both subtasks have succeeded, so compose their results
        return new Response(user.get(), order.get());
    }
}

💡 Why It Matters

Makes parallel code easier to reason about.
Simplifies error handling, cancellation propagation, and resource management.
Promotes better structured and maintainable multithreaded applications.

⚠️ Considerations:
Still under preview (5th round). Developers must migrate gradually and understand ForkJoin-based semantics.

Module Import Declarations

✅ Key JEPs

JEP 476: Module Import Declarations (Preview, Java 23)
JEP 494: Module Import Declarations (Second Preview, Java 24)
JEP 511: Module Import Declarations (Final, Java 24)

🔍 What’s New

Module import declarations allow a Java source file to declare which modules it depends on — directly in the source code.

Instead of relying solely on the module system (via module-info.java) or command-line options to express module dependencies, developers can now specify module usage within individual .java files using the new import module syntax.

✅ Syntax Example

import module com.example.graphics;

import com.example.graphics.Image;

This tells the compiler that this file uses types from the com.example.graphics module.

💡 Why It Matters

Simplifies modular development: Especially useful for small programs, scripts, or single-source-file applications.
Reduces boilerplate: No need for a separate module-info.java just to use a few modules.
Improves clarity: The source file shows all its external module dependencies up front.
Enables better tooling: IDEs and compilers can provide better feedback and autocomplete when module dependencies are declared explicitly.

⚠️ Considerations

Using one or more module import declarations leads to a risk of name ambiguity due to different packages declaring members with the same simple name

Conclusion

From enabling pre-super() logic to opening Java to native interop and empowering concurrent designs, these JEPs collectively represent Java’s steady transformation into a modern, expressive, and high-performance platform. While many of these features are still in preview, developers are encouraged to explore them now to prepare for their production maturity in the near future.

Forem: Vahram Papazyan

Modern Java Features: Part 2 - From Java 22 to 25

Compact Source Files & Instance Main Methods

✅ Key JEPs

🔍 What’s New

💡 Why It matters

⚠️ Considerations

Primitive types in patterns, instanceof, and switch

✅ Key JEPs

🔍 What’s new

💡 Why it matters

⚠️ Considerations

Scoped Values (Preview)

✅ Key JEPs

🔍 What’s new

💡 Why it matters

⚠️ Considerations

ZGC: Low-latency garbage collector

✅ Key JEPs

🔍 What it does

💡 Why it matters

⚠️ Considerations

Ahead-of-time class loading & linking

✅ Key Jeps

🔍 What the JEP does

💡 Why it matters

⚙️ How it works (high Level)

⚠️ Considerations

Conclusion

Modern Java Evolution: Part 1 - From Java 22 to 25

Flexible Constructor Bodies

✅ Key JEPs

🔍 What’s New

💡 Why It Matters

⚠️ Considerations

Foreign Function & Memory API

✅ Key JEPs

🔍 What’s New

💡 Why It Matters

⚠️ Considerations

Unnamed Variables & Patterns

✅ Key JEPs

🔍 What’s New

💡 Why It Matters

⚠️ Considerations

Stream Gatherers

✅ Key JEPs

🔍 What’s New

💡 Why It Matters

Structured Concurrency

✅ Key JEPs

🔍 What’s New

💡 Why It Matters

Module Import Declarations

✅ Key JEPs

🔍 What’s New

✅ Syntax Example

💡 Why It Matters

⚠️ Considerations

Conclusion

Primitive types in patterns, `instanceof`, and `switch`