Java keeps evolving! Java 26 is out. The release brings many features aimed at optimizing Java applications and drops support for applets. We cover all of this and more below.

Currently, Java ships a new version every six months. The last release was Java 25 in September 2025, so March 2026 meant it was time for Java 26.

Java 25 was an LTS release; this version, however, isn't designed for long-term support. The new version didn't add as many features as the previous one, but it brought important changes to the language. After all, it's not about quantity :)

So, what's new in Java 26?

JEP 500 Prepare to Make Final Mean Final

The JEP link.

A curious name. What does it mean, though? Here's some background info.

Starting with JDK 5, we can use reflection to change the value of final fields (java.lang.reflect#setAccessible and java.lang.reflect#set). Handy for those who need it (but how often do you modify final fields?). Either way, it's not ideal for two other reasons:

1. When working with the final field, you expect the primitive object to never change after initialization. But with reflection in the picture, the specs and the actual behavior don't match up.
2. You can't perform optimizations on final fields. Constant folding is impossible if there's any chance the value or expression in the constant could change.

To eliminate inconsistencies and enable optimization for everything related to final fields, starting with this JEP, developers will gradually lose the option to modify them. How?

In Java 26, the JVM will issue special warnings when the final value is changed. In future versions, attempting to modify the final field will result in an exception.

This approach gives developers time to adapt their applications and libraries to the change. The JVM, on the other hand, will have room for optimization. Also, there will be more consistency for final fields.

JEP 504 Remove the Applet API

The JEP link.

The nine-year saga is coming to an end. Yes, now applets are gone.

Here's the whole timeline of the applet removal:

1. 2017 (JEP 289, JDK 9), applets are marked as Deprecated because browsers no longer support them.
2. 2018 (JDK 11), Appletviewer, which enabled testing applets outside a browser, is removed. No more applet testing in the JDK.
3. 2020 (JEP 398, JDK 17), the applet API is marked with forRemoval=true.
4. 2024 (JEP 486, JDK 24), SecurityManager, which handled security during applet execution, is removed.

So now, in 2026, nine years after the efforts to remove the Applet API began, this whole story has come to its logical conclusion!

They weren't even 33 years old... Gone too soon, never truly understood.

JEP 517 HTTP/3

The JEP link.

Java 11 introduced HttpClient, which replaced the deprecated HttpUrlConnection. It handles HTTP requests using HTTP/1.1 and HTTP/2. The HTTP/3 protocol was standardized in 2022. According to W3Techs, more than a third of web servers already support it.

So, the time has come: this JEP adds support for HTTP/3 requests to HttpClient.

To make client requests use HTTP/3, the proper flag must be explicitly set when configuring HttpClient:

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

Alternatively, you can do the same when configuring the query:

var request = HttpRequest.newBuilder(URI.create("https://openjdk.org/"))
                         .version(HttpClient.Version.HTTP_3) // <=
                         .GET().build();

However, if the target server doesn't support HTTP/3, the request will be downgraded under the hood—first to HTTP/2, and then to HTTP/1.1 if necessary.

The benefits of using HTTP/3 include:

1. Faster handshakes.
2. More reliable data transmission.
3. Fixing the head-of-line blocking issue.

JEP 526 Lazy Constants (Second Preview)

The JEP link.

On to the preview features. This JEP is a direct follow-up to JEP 502: Stable Values. Let's briefly recap what it's about.

These changes will add an API for defining lazy constants. Currently, static constants are initialized when a class is loaded, even if they won't be used until way later (or at all). This JEP will introduce an entity that combines immutability with lazily initialized values—only when accessed.

The advantages include better startup performance and the ability to optimize these values just like constants.

In the second preview:

• The API under development has been renamed from StableValue to the higher-level LazyConstant.
• Some low-level methods and factories have been removed. Only high-level factories that take values directly remain available.
• For optimization purposes, null is no longer allowed as a computed value.

JEP 529 Vector API (Eleventh Incubator)

The JEP link.

If you need a refresher on what the Vector API is, here's a quick overview.

The Vector API enables vector computation to Java at the CPU level and provides data-level parallelism. The goal is to pair raw performance with developer-friendly, high-level API.

What's vector computation?

Vector computation is a way for processors to operate on data vectors using the SIMD (Single Instruction, Multiple Data) architecture, where a single machine instruction is applied in parallel to all elements of the vector.

First, it's worth noting the irony of this JEP staying in the Incubator for the 11th time. Simple math calculations reveal that the feature was first introduced in Java 16 (JEP 338).

According to the authors themselves, there are no significant changes in this particular iteration. This feature is scheduled for release with Project Valhalla, and once that lands, Vector API will be available in Preview. No firm release date yet, but hopefully, it'll be out as soon as possible. After all, both the Vector API and Value Classes sound like cool and niche features.

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

The JEP link.

That bring us to the final JEP on today's list; the 4th preview of a feature that enables using primitives in pattern-matching constructs with the instanceof and switch.

It may look something like this. The switch statement before:

switch (x.getStatus()) {
    case 0 -> "okay";
    case 1 -> "warning";
    case 2 -> "error";
    default -> "unknown status: " + x.getStatus();
}

The after:

switch (x.getStatus()) {
    case 0 -> "okay";
    case 1 -> "warning";
    case 2 -> "error";
    case int i -> "unknown status: " + i;
}

This fourth preview doesn't introduce any new APIs or features, but it does clarify and expand the way the language behaves with two new things:

1. Safety of conversion is a formalization that describes possible primitive type conversions for pattern matching (specifying which are safe, which may result in data loss, and which are uncompilable).
2. Dominance is a compile-time check ensuring that one case branch doesn't dominate another. If it does, Java 26 will now throw a compilation error. As a result, some Java 25 code won't compile in Java 26.

Here are some examples of uncompilable constructs:

byte x = ...;
switch (x) {
    case short s -> {}
    case 42      -> {}   // error: dominated since 42 can be
                         // converted unconditionally exactly to short
}

Or:

int x = ...;
switch (x) {
    case int _      -> {}  // unconditional pattern
    case float _    -> {}  // error: dominated
}

Summary

Java 26 didn't ship a ton of new features or APIs on its own. Still, this update brought quite a few changes that enhanced what's already there. The final modifier, Lazy Constants, and everything else are part of the ongoing trend toward optimizing Java program execution.

It's great that Java is never standing still. The optimizations, the ongoing API work, and everything in between are a clear sign that Java is more alive than ever and still going strong.

You can find the original descriptions of all the changes here. If you'd like to read our previous reviews of new Java versions, check out the list below:

• What's new in Java 25;
• What's new in Java 24.