Java 26 - the new features

Last Refreshed // 2026-02-05

Release date (estimated): 2026-03-17

JEP release: https://openjdk.org/projects/jdk/26/

TL;DR

Java 26 is a non-LTS release focused mainly on JVM and GC improvements.
Most application developers will not see new language features.
Upgrade primarily if your project requires performance tuning and startup optimization.

Who should consider upgrading?

  • Teams experimenting with GC tuning or startup optimization
  • Platform engineers
  • People testing preview features for future Java versions

Who can safely skip?

  • Typical business applications
  • Projects waiting for the next LTS

New cool features that you can use

None — at least nothing that directly impacts everyday application development.
You will find some minor improvements that prepare for bigger future changes in the platform.

Changes without direct impact on your daily development

JEP 500: Prepare to Make Final Mean Final

https://openjdk.org/jeps/500

This JEP introduces a warning if a final field value is mutated ... yes ... final doesn't mean final.

As you should know, final in Java can be confusing (it refers to the reference and not the value of a constant, read more here, it's a common interview question: http://marmo.dev/java-the-final-keyword)

Not only is confusing, but it's not always true, in particular a final can be changed using deep reflection. This is not common, but it means that your application that is managing the money of clients could potentially behave differently that what you expect.

As mentioned in the JEP description:

Unfortunately, the expectation that a final field cannot be reassigned is false.
Final fields are, in reality, as mutable as non-final fields. We cannot rely on final fields to be immutable when reasoning about correctness, and we cannot use final fields to construct the deeply immutable graphs of objects that enable the JVM to deliver the best performance optimizations.

In the description there is an example of how to 'hack' a final field using deep reflection:

// A normal class with a final field 
class C { 
  final int x; 
  C() { x = 100; } 
} 
 
// 1. Perform deep reflection over the final field in C 
java.lang.reflect.Field f = C.class.getDeclaredField("x"); 
f.setAccessible(true);      // Make C's final field mutable 
 
// 2. Create an instance of C 
C obj = new C(); 
System.out.println(obj.x);  // Prints 100 
 
// 3. Mutate the final field in the object 
f.set(obj, 200); 
System.out.println(obj.x);  // Prints 200 

In a normal project, without crazy mental developers, this should not be an issue, but who knows ... Maybe some hero hacked a class or dependency to 'fix' some problem.

Just a reminder, final fields (declared or not) can be optimized by the JVM, evaluating them only once and not every time they are used (Constant Folding).

JEP 516: Ahead-of-Time Object Caching with Any GC

https://openjdk.org/jeps/516

This is an improvement in the garbage collector performances if you are using AOT Cache with HotSpot JVM.

Most of the projects use HotSpot JVM (aka 'standard' JVM) and don't use AOT Cache (introduced in Java 24). This improvement could concern you if you need to tune the starting speed of your application or microservice.
For common business applications with deployment downtime window or with rolling deployments it's not a big deal.

FeatureClass Data Sharing (CDS)AOT Cache (Java 24)GraalVM Native Image
What is cached?Parsed MetadataLoaded & Linked ClassesFull Native Binary
Startup BoostModerate (~10-20%)High (~40%+)Instant
GC supportAll GCsAny GC (New in 26)Custom (Substrate VM)
Ease of UseEasyModerate (Needs Training)Hard (Requires Refactoring)
ReflectionFull SupportFull SupportRequires Configuration
PortabilityHigh (Any JVM)Low (Specific OS/Arch)Zero (Native Binary)
ComplexitySet & ForgetNeeds "Training" RunHigh (Closed-world)

JEP 517: HTTP/3 for the HTTP Client API

https://openjdk.org/jeps/517

Now you can send requests using HTTP/3 protocol.
HTTP/3 works already in the major browsers.
The most notable difference in HTTP/3 is that it uses a protocol named QUIC over UDP instead of TCP.
Probably this is not a priority for your project if you are not developing videogames, streaming, mobile-heavy backends, or trading application.
QUIC hadles much better network switches and is more efficient than TCP.

To do so you have to explicitly declare the request as HTTP/3 in the code:

var client = HttpClient.newBuilder() 
                       .version(HttpClient.Version.HTTP_3) 
                       .build(); 

JEP 522: G1 GC: Improve Throughput by Reducing Synchronization

https://openjdk.org/jeps/522
If your application is using the default Garbage Collector (G1) you can benefit from this improvement.
If you are using microservices and you don't specify the GC ... maybe Java switched automatically to Parallel GC or Serial GC according to the memory available ... better to check it. ;-)

This is another free improvement that should not affect or interest you ... if you are not tuning the Garbage Collector.

Removed / Deprecated APIs

JEP 504: Remove the Applet API

  • https://openjdk.java.net/jeps/504
    Applets ... do you remember them? They were mainly used to create small games and effects on the web 20+ years ago.
    With Flash (another disappeared technology) applet became quickly obsolete. Java tried to replace the technology introducing JavaFX and, de facto, abandoning it quickly.

Applets API was deprecated already in Java 17, now it's time to remove it from the JDK.
You should not be impacted by this change if you and your project have not been forgotten in the basement of a big Corp that uses IE.

This will be removed from the JDK:

  • java.applet.Applet
  • java.applet.AppletContext
  • java.applet.AppletStub
  • java.applet.AudioClip
  • java.beans.AppletInitializer
  • javax.swing.JApplet
  • java.beans.Beans
  • javax.swing.RepaintManager

New Toys - Preview features

These features are not available in the standard JDK. You can activate them if you want to test the 'future Java' or if you want to contribute to the Java development with feedback.

java --enable-preview 
javac --enable-preview --release 26 

JEP 526: Lazy Constants (Second Preview)

https://openjdk.org/jeps/526

This is a cool new feature, Kotlin has already something similar https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/lazy.html

With lazy constants you can define a constant without directly initializing it. Java will initialize the constant only when it is used in the code.
This is particularly useful for constants that are expensive to compute.
This will be useful to increase the level of immutability of your code.
Immutability is an important principle used in other languages as default, Java is trying to add more and more features that go in this direction (e.g. record).

Here you have a preview of the interface LazyConstant documentation:

public class Component { 
 
    // Creates a new uninitialized lazy constant 
    private final LazyConstant<Logger> logger = 
            LazyConstant.of( () -> Logger.create(Component.class) ); 
 
    public void process() { 
        logger.get().info("Process started"); 
        // ... 
    } 
 } 

JEP 530: Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

https://openjdk.org/jeps/530

Enhance pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types.

I will add some examples in the future.

JEP 525: Structured Concurrency (Sixth Preview)

https://openjdk.org/jeps/525

Simplify concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.

JEP 524: PEM Encodings of Cryptographic Objects (Second Preview)

https://openjdk.org/jeps/524

Introduce an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-used Privacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects.

JEP 529: Vector API (Eleventh Incubator)

https://openjdk.org/jeps/529

Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPUs, thus achieving performance superior to equivalent scalar computations.

AI Feature ... the last in the list ... but crucial for the future of Java, this is mainly useful for high-performance computing, AI workloads, image processing, and scientific applications.

Final thoughts

Java 26 is a maintenance-oriented release that prepares the ground for future language and runtime evolution.
If you stay on LTS releases, you can safely skip it.
If you like to experiment or tune performance, it’s a solid incremental step forward.