Java 26: Mutating Final Fields Using Reflection

Java 26 introduces a new warning when code uses reflection to mutate final fields. This change comes from JEP 500: Prepare to Make Final Mean Final, and is part of Java’s ongoing move toward stronger integrity and better JVM optimisations. The JVM relies on the assumption that final fields never change in order to perform optimisations such as constant folding and safe object initialisation in concurrent code. However, deep reflection APIs like Field.setAccessible(true) and Field.set(...) have historically allowed any code to mutate final fields at runtime, breaking those guarantees.

Consider the following code that reflectively mutates a final field:

public class Foo {

  final int x;

  Foo() {
    x = 100;
  }

  public static void main(String... args) 
                          throws Exception {

    Foo obj = new Foo();

    System.out.println(obj.x);
    
    java.lang.reflect.Field f =
            Foo.class.getDeclaredField("x");
    f.setAccessible(true);
    f.set(obj, 200); // mutate the final field

    System.out.println(obj.x);
  }
}

In older JDK versions, this would silently mutate the supposedly immutable final field.

In JDK 26, it still works, but produces warnings:

100
WARNING: Final field x in class Foo has been mutated reflectively by class Foo in unnamed module @764c12b6
WARNING: Use --enable-final-field-mutation=ALL-UNNAMED to avoid a warning
WARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled
200

In a future JDK release, these operations are expected to fail unless explicitly enabled using --enable-final-field-mutation=ALL-UNNAMED or for specific modules --enable-final-field-mutation=M1,M2.

So, stop mutating final fields! final means final.

Java 26: Thread.stop() Removed

Java 26 finally removes Thread.stop(), one of the oldest deprecated methods in the JDK!

This method has long been considered inherently unsafe because it does not give the target thread a chance to clean up resources, release locks safely, or complete critical sections of code. If a thread was stopped while mutating shared state, other threads could observe partially updated data and corrupted state.

What should you use instead?

Modern Java code should use cooperative cancellation instead of forcibly terminating threads, to allow them to stop safely at a controlled point in execution. Typically this means:

• using interruption (Thread.interrupt())
• checking interruption status
• using structured concurrency or executors
• designing tasks to terminate gracefully

Java 26: Lazy Constants

In my previous post, I wrote about Stable Values introduced in Java 25. Java 26 renames them from Stable Values to Lazy Constants. While the underlying idea remains the same, the new name better reflects the intended use case: immutable values that are initialised lazily. This is a preview language feature.

A Lazy Constant allows you to defer the initialisation of immutable data until it is actually needed, while still allowing the JVM to optimise access to that data as though it were a regular final field.

Here is the example from the previous post, rewritten using a LazyConstant:

public class Controller {

    private final LazyConstant<ExpensiveResource> resource =
            LazyConstant.of(() -> new ExpensiveResource());

    public void process(String request) {
        resource.get().get(request);
    }
}

Initially, the lazy constant is uninitialised. The first call to resource.get() invokes the lambda expression, creates the ExpensiveResource, stores it permanently, and returns it. Subsequent calls simply return the already initialised value. Importantly, the initialisation function is guaranteed to execute only once, even under concurrent access.

Under the hood, the content of a LazyConstant is stored in a non-final field annotated with the JDK-internal @Stable annotation. This tells the JVM that the field will never change after it is written. Due to this guarantee, the JVM can treat the value like a constant, provided that the reference to the stable value is final, and perform constant-folding optimisations, even through multiple layers of stable values.

fahd.blog in 2025

Happy 2026, everyone!

I'd like to wish everyone a great start to an even greater new year!

In keeping with tradition, here's one last look back at fahd.blog in 2025.

During 2025, I posted 8 new entries on fahd.blog. I am also thrilled that I have more readers from all over the world! Thanks for reading and especially for giving feedback.

Top 3 posts of 2025:

• Java 24: Structured Concurrency
• Java 24: Scoped Values
• Java 24: Primitive Types in Patterns, instanceof, and switch

I'm going to be writing a lot more this year, so stay tuned for more great techie tips, tricks and hacks! :)

Related posts:

• fahd.blog in 2024
• fahd.blog in 2023
• fahd.blog in 2022
• fahd.blog in 2021
• fahd.blog in 2020
• fahd.blog in 2019
• fahd.blog in 2018
• fahd.blog in 2017
• fahd.blog in 2016
• fahd.blog in 2015
• fahd.blog in 2014
• fahd.blog in 2013

Java 25: Stable Values

Java 25 introduces Stable Values, which are objects that hold immutable data. They let you initialise immutable fields lazily, while still allowing the JVM to treat them as constants, and thus perform the same optimisations (such as constant-folding) that are done for final fields. This is a preview language feature.

Consider the following example:

public class Controller {
    private final ExpensiveResource resource = new ExpensiveResource();
    
    public void process(String request) {
        resource.get(request);
    }
}

The problem here is that, since resource is a final field, it must be initialised eagerly, which means creating a Controller can be slow. It's also unnecessary to create the expensive resource if the process method is never called during the runtime of the application. In order to "defer immutability" and lazily initialise fields, we have to use complex workarounds such as the class-holder idiom, as shown below:

public class Controller {
    public static ExpensiveResource getResource() {
        class Holder {
            private static final ExpensiveResource RESOURCE =
                    new ExpensiveResource();
        }
        return Holder.RESOURCE;
    }

    public void process(String request) {
        getResource().get(request);
    }
}

This is where Stable Values come in.

Here is the same class, rewritten using a StableVaue:

public class Controller {
    private final StableValue<ExpensiveResource> resource = StableValue.of();

    public ExpensiveResource getResource() {
        return resource.orElseSet(() -> new ExpensiveResource());
    }

    public void process(String request) {
        getResource().get(request);
    }
}

Initially, the stable value holds no content. When the orElseSet method is invoked for the first time, the expensive resource is initialised and set into the stable value, and subsequent calls will simply return it. The orElseSet method guarantees that the provided lambda expression is evaluated only once, even when it is invoked concurrently.

A more convenient way to use stable values is via a Supplier instead, as shown below:

public class Controller {
    private final Supplier<ExpensiveResource> resource = 
        StableValue.supplier(() -> new ExpensiveResource());

    public void process(String request) {
        resource.get().get(request);
    }
}

Using a stable value supplier, rather than a stable value, is more readable because the declaration and initialisation of the resource field are now together.

Under the hood, a stable value is a non-final field annotated with the JDK-internal @Stable annotation. This tells the JVM that the field will never change after it is written. Due to this guarantee, the JVM can treat the value like a constant, provided that the reference to the stable value is final, and perform constant-folding optimisations, even through multiple layers of stable values.