Lazily initializing fields in Java is error-prone and undermines constant-folding. JDK 26 comes with JEP 526, which previews LazyConstant, a type that lazily initializes a value through a given Supplier. It executes that supplier at most once successfully and then assigns the value to a field annotated with @Stable, which allows constant folding. This API is also a poster child for how OpenJDK develops and evolves features.

Links:

• JDK 26
• JEP 526
• JEP Draft for Lazy Constants in JDK 27
• Inside Java Newscast #101 on reflective final field mutation
• Inside Java Podcast #37 with Per Minborg - Efficient Initialization Using Stable Values
• Inside Java Podcast #42 with John Rose - From Sumatra to Panama, from Babylon to Valhalla

Make sure to also check the Duke’s Corner podcast on dev.java.

Additional resources

• Inside.java : News and views from members of the Java team at Oracle
• Dev.java : The Destination for Java Developers
• OpenJDK
• Oracle Java

For more episodes, check out Inside Java, our YouTube playlist, and follow @Java on Twitter.

Contact us here.

Java 26 is getting all packaged up to be shipped worldwide! As with every release of the JDK there are a number of new features, improvements, changes in behavior, and more that developers should be aware of before upgrading. In this episode of the Inside Java Newscast we will review all the noteworthy changes coming in Java 26 that will impact developers.

Make sure to check the show-notes.

HTTP/3 Support

JEP 517 adds support for HTTP/3 to the HttpClient. It’s important to note that support is only be added, but the default will remain HTTP/2, which has been the case since the HttpClient was initially added in JDK 11.

The preferred protocol version can be set at the HttpClient level:

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

And at the HttpRequest level:

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

The HttpClient offers options for navigating the transition between HTTP/1.1 and HTTP/2 to HTTP/3 covered below.

Connecting to HTTP/3 services

Part of the reason for not setting HTTP/3 as the default for HttpClient, is because HTTP/3 uses a new transport protocol, QUIC, an update from the TCP protocol used by HTTP/1.1 and HTTP/2, and HTTP/3 is not as widely deployed as HTTP/1.1 or HTTP/2. However while QUIC offers many advantages, the addition of a new transport protocol does bring some complications. Specifically there’s no way to know which transport protocol is being used ahead of time. To that end, below are four strategies that can be used with the HttpClient that can handle working with HTTP/1.1, HTTP/2, and HTTP/3 services.

Send a HTTP/3 Request First

HTTP/3 should be used when available, and with services migrating towards HTTP/3 an optimistic approach can be taken to attempt to connect using HTTP/3 first, and only fall back to HTTP/2 or HTTP/1.1 if a connection cannot be established. This can be done by not setting the protocol version at the client level, but setting it at the request level:

var client = HttpClient.newBuilder().build();

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

Send HTTP/3 and HTTP/2 or HTTP/1.1 Requests in Parallel

Sending requests in serial, like in the above example, can increase latency, espeically when a fallback is likely. Alternatively HTTP/3 and HTTP/2 or HTTP/1.1 requests can be sent in parallel, and the first one that succeeds will be used. This can be accomplished by setting the preferred version to HTTP/3 at the client level, but not setting a preferred version at the request level:

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

var request = HttpRequest.newBuilder(URI.create("https://openjdk.org/"))
                         .GET().build();

Send a HTTP/2 or HTTP/1.1 Request First and Redirect to HTTP/3 if Available

If it’s likely the service you are connecting to does not support HTTP/3, then a pessimistic approach could be taken, and send a HTTP/1.1 or HTTP/2 request first, and only switching to HTTP/3 if the serivce says its available. This can be done by setting the Http3DiscoveryMode.ALT_SVC option:

var client = HttpClient.newBuilder()
                       .build();

var request = HttpRequest.newBuilder(URI.create("https://openjdk.org/"))
						 .setOption(HttpOption.H3_DISCOVERY, Http3DiscoveryMode.ALT_SVC)
						 .GET().build();

Only Use HTTP/3

The last strategy would be to only use HTTP/3 and not fall back if the server does not reply with HTTP/3. This can be done by setting the Http3DiscoveryMode.HTTP_3_URI_ONLY option:

var client = HttpClient.newBuilder()
                       .build();

var request = HttpRequest.newBuilder(URI.create("https://openjdk.org/"))
						 .setOption(HttpOption.H3_DISCOVERY, Http3DiscoveryMode.HTTP_3_URI_ONLY)
						 .GET().build();

Uploading File Regions

A new static method, java.net.HttpRequest.BodyPublishers.ofFileChannel(FileChannel chan, long position, long size) has been added. ofFileChannel(FileChannel chan, long position, long size) allows for a specific region of a file to be uploaded. For large files, this can avoid having to read the entire file into memory, and can be leveraged to slice a file it chunks and uploaded in parallel.

https://bugs.openjdk.org/browse/JDK-8329829

Signature Schemes and Named Groups Usage Fix

During the setup of new connections, HttpClient now uses the signature schemes and named groups configured on SSLParameters, like in the example below, when negotiating the TLS handshake. Previously these configured values were ignored.

final SSLParameters sslParameters = new SSLParameters();
sslParameters.setNamedGroups(new String[]{namedGroup});

HttpClient.newBuilder()
	.sslContext(sslBundle.createSslContext())
	.sslParameters(sslParameters)
	.build();

https://bugs.openjdk.org/browse/JDK-8367112

Timeout Update

The HttpClient request timeout set using java.net.http.HttpRequest.Builder::timeout previously applied only until the response headers were received. Its scope has now been extended to also cover the consumption of the response body, if present. In most cases this should align with expected behavior of canceling a long running connection, but if your application frequently deals with large response bodies and depends upon the previous behavior, you will need to update your timeout values accordingly.

https://bugs.openjdk.org/browse/JDK-8208693

Content-Length Removed for non-POST/PUT Requests

The HttpClient will no longer send a Content-Length header on HTTP/1.1 request for non-POST/PUT methods which contain no body. This follows RFC9110 semantics. If your application depends on the Content-Length header, it can be added using HttpRequest.Builder, and by updating the jdk.httpclient.allowRestrictedHeaders property to include Content-Length.

https://bugs.openjdk.org/browse/JDK-8358942

Missing File Exception Update

Previously the java.net.http.HttpRequest.BodyPublishers::ofFile(Path) method could throw a java.io.NoSuchFileException if the provided Path was not associated with the default file system. This inconsistency has been removed by mapping these to java.io.FileNotFoundException, in line with the ofFile(Path) API specification.

https://bugs.openjdk.org/browse/JDK-8358688

Max-Age Updates

java.net.HttpCookie has been updated to correctly return the value of Max-Age when when calling getMaxAge() for cookies that have both Expires and Max-Age attributes. This follows RFC 6265 specifies that the Max-Age attribute should take precedence over the Expires attribute.

https://bugs.openjdk.org/browse/JDK-8351983

Java 26 ended up being a pretty important release for HttpClient users. With HTTP/3 support being added as well as several other updates. If you’d like to learn more about the HttpClient, and all the other features coming in Java 26 and beyond, consider attending JavaOne March 17-19th in Redwood Shores, California. Tickets are on sale now as well as the full session list at: https://javaone.com.

The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of the quality outreach sent to the projects involved. To learn more about the program, and how-to join, please check here.

Metal Is Now the Default Rendering Pipeline on macOS

On macOS, the default JavaFX rendering pipeline has been switched to Metal since JavaFX 27 Early Access (EA) build 3. Metal provides improved performance and better compatibility on modern hardware.

The Metal pipeline was implemented under JDK-8271024 in JavaFX 26 as an optional pipeline, with the OpenGL-based ES2 pipeline as the default. Starting with JavaFX 27 EA build 3, Metal is now the default rendering pipeline on macOS.

JavaFX 27 EA builds are now available for download and testing. You can share your feedback on the openjfx-dev list (registration required), through JBS or bugreport.java.com.

If you need to revert to the previous ES2 pipeline, you can do so by adding the option -Dprism.order=es2 to your Java command.

References to metal blogs published earlier:

• Quality Outreach Heads-up - JavaFX 26: Temporary Switch to macOS Metal Rendering Pipeline
• Quality Outreach Heads-up - New macOS JavaFX Metal Early-Access builds

Ahead-of-Time Computation for ZGC Users

JEP 516 Ahead-of-Time (AOT) Object Caching with Any GC, brings the benefits of AOT introduced in Java 24 (JEP 483) and 25 (JEPs 514 & 515), to Z Garbage Collector (ZGC) users. AOT improves the startup and warm up performance of Java applications, by storing information from a previous run of an application in a cache that can be accessed on subsequent runs. To learn more about AOT, watch my video on this subject.

JEP 516

G1 Garbage Collector Updates

G1, Java’s default garbage collector, remains under active development, and there are several notable changes coming in Java 26.

G1 GC: Improve Throughput by Reducing Synchronization

The throughput of the G1 garbage collector has been improved in Java 26 by reducing the frequency of synchronization with application threads. This was done by introducing a second card table allowing the optimizer and application threads to run freely. This also had the second order effect of reducing the write barriers in G1 from 50 intructions to 12.

Testing has shown that these changes have improved throughput by 5-15% percent, with applications that do heavy modification to object-reference fields seeing the most benefit. Additionally this new design is more efficent that the previous auxillry data structure, which resulted in a slight descrease in pause times. Lastly the second card table can in some cases slightly reduce memory overhead; each card table requiring about 2MB of native meory per 1GB of heap capacity. In cases where it does consume more memory than before, the difference is trivial.

JEP 522

Humongous Object Reclamation

The G1 garbage collector now eagerly reclaims eligible humongous objects (objects occupying more than half a heap region) containing references.

This change allows for the prompt recovery of memory previously held by such objects, particularly if they are short-lived, improving garbage collection efficiency and reducing heap usage. Previously such humongous objects were only reclaimed during full gcs.

This change applies to both discrete humongous objects, as well as to humongous arrays of references (i.e. Object[]).

JDK-8048180

G1 Overhead Limit

The G1 garbage collector now throws an OutOfMemoryException when the garbage collection overhead is more than the GCTimeLimit percent (default 98) and the free Java heap is less than the GCHeapFreeLimit percent (default 2) for five consecutive garbage collections. This can help prevent GC thrashing in such scenarios and mirrors the behavior implemented in the Parallel GC.

This feature is enabled by default. It can be disabled using the -XX:-UseGCOverheadLimit option.

JDK-8212084

Transparent Huge Pages Support

G1 can again properly utilize Transparent Huge Pages (THP) on systems with the THP mode configured as madvise, this resolves an issue introduced in Java 25. This issue has also been backported to 25.0.2.

JDK-8366434

JVM Flag Updates

There are a number of updates to JVM flags in Java 26.

InitialRAMPercentage Default Value Removed

InitialRAMPercentage is being changed from 1.5625 (1/64) to 0. The previous default value was last set in 2007. At that time, the value of 1.5625 was a reasonable assumption, but as available system memory has increased, it can result in excessively large heap sizes. This could result in wasted resources and slower startup performance.

To address this the default value of InitialRAMPercentage has been removed (set to 0), which matches with MinHeapSize and InitialHeapSize, which will default to using JVM ergonomics for setting these values. Users could, if needed, set these values using -Xms. It is also still possible to set InitialRAMPercentage explicitly; -XX: InitialRAMPercentage=[0.0-100].

JDK-8371986

Server and Client Flags Deprecated for Removal

The flags AlwaysActAsServerClassMachine and NeverActAsServerClassMachine are marked as deprecated for removal. The primary benefit of these flags was driving ergonomics for GC selection: G1 being used on server class machines, and Serial on client machines. However, with the future introduction of JEP 523, which makes G1 the default GC in all environments, there’s is little difference between the two JVM arguments.

JDK-8370843

AggressiveHeap Deprecated for Removal

The flag AggressiveHeap has been marked as deprecated for removal. AggressiveHeap was originally added to satisfy specific benchmarks, but lacks transparency. If your application depended on the behavior of AggressiveHeap, you can recreate it with the following set of flags:

-XX:+UseParallelGC -XX:+UseLargePages 
-XX:-ResizeTLAB -XX:TLABSize=256K 
-XX:YoungPLABSize=256K -XX:OldPLABSize=8K 
-XX:ThresholdTolerance=100

And additionally set the following flags to the relevant values based on your systems resources:

• -Xmx and -Xms to half the available physical memory
• -XX:NewSize to 3/8 of available physical memory
• -XX:MaxNewSize to the value of -XX:NewSize

JDK-8370813

MaxRAM Deprecated for Removal

The MaxRAM flag has been marked as deprecated for removal as the JVM can accurately detect physical RAM and set reasonable commit limits. Often times, users were setting other JVM flags: MaxRAMPercentage, MinRAMPercentage or InitialRAMPercentage as a means of getting around MaxRAM’s default of 128GB. Users should instead use -Xmx and -Xms for controlling heap size.

JDK-8369346

JMX Updates

JMX, Java Management Extensions, is a technology that can be used to provide a view in the a running JVM. There were a number of updates and changes to the JMX API in Java 26.

Garbage Collector CPU Usage

A new method getTotalGcCpuTime() has been added to java.lang.management.MemoryMXBean, which returns a long result with the accumulated CPU time in nanoseconds during the critical section and/or after JIT warmup.

JDK-8368527

Protocal Requires for JMXServiceURL

The class javax.management.remote.JMXServiceURL requires that a protocol is specified when using its String constructor. In prior releases when a null protocol was supplied to the constructor, the following exception was thrown:

java.net.MalformedURLException: Unsupported protocol: jmxmp
        at java.management/
        ...

This is inaccurate as jmxmp was a default value, but isn’t part of the JDK. This has been updated to not select jmxmp and instead print out the follow and more clear message:

java.net.MalformedURLException: Unsupported protocol: Misssing protocol name
        at java.management/
        ...

JDK-8347114

The classes javax.management.AttributeList, javax.management.relation.RoleList, and RoleUnresolvedList, have been updated to reject objects of the wrong type, as previous those objects were only verified when the asList() method was called.

JDK-8359809

MBeanServer Exception Change

The javax.management.MBeanServer:eregisterMBean() now throws a RuntimeOperationsException instead of NullPointerException when invoked with a null “object” parameter. This correction aligns the implementation with the specification.

JDK-8364227

Other Changes

There are a couple of other updates that don’t neatly fit into the above catagories.

C2 JIT Support Enhancement

The C2 JIT compiler can now compile Java methods with a large number of parameters (greater than 30). Previously, C2 would bail out when it attempted to compile such methods, causing the JVM to fall back to C1-compiled code or the interpreter.

JDK-8325467

Serial GC Eden Space

Prior to Java 26, the ordering of the young generation (YoungGen) in the Serial GC was eden follow by the to/from spaces (survivor regions). This meant that it was difficult for eden to expand to satisfy an allocation request, possibly resulting in a premature OutOfMemoryException (OOME).

With Java 26, eden has been moved to be after the to/from space, allowing it to possibly grow to the end of YoungGen to satisfy an allocation request. This might mean it grows beyond the limit governed by SurvivorRatio. However this behavior is desirable as it can avoid an OOME and VM termination.

JDK-8368740

Java 26 will be released on March 17th! If you are able to, be sure to attend JavaOne on March 17-19th, in Redwood Shores, California. A large part of the JDK Engineering team will be there, including some of the engineers who worked on the very issues covered in this article. It can be a great opportunity to learn about Java for the stewards of Java! For more check out https://javaone.com, hope you see you there!

How do you monitor your JVM applications effectively? One powerful option is JDK Flight Recorder (JFR).

JFR simplifies troubleshooting and profiling by capturing detailed JVM event data—and with the JFR Streaming API, you can access those insights in real time. But what if you could go further and stream live JFR data straight into an AI system to enhance monitoring, accelerate troubleshooting, and even help prevent issues before they occur?

In this session, we’ll demonstrate how to use JFR with the latest JDK features to build self-improving applications with the help of AI. Using a real-life simulated example, you’ll learn how to:

• Capture and stream JFR data in real time
• Integrate JVM event data into an AI-based system
• Automatically spot performance bottlenecks and unusual behavior
• Build better tools for debugging and monitoring

By the end of this talk, you’ll have a clear roadmap for combining JFR and AI to improve observability and elevate the troubleshooting experience for your JVM applications.

Recorded at Jfokus 2026.

HTTP/3 is the next version of the internet’s most important application layer protocol. But, somewhat surprisingly, it uses UDP (via the new QUIC protocol) instead of TCP/IP, which has implications for the number of initial roundtrips, HTTP version selection, and time to first byte but also adoption and evolution. Java 26 supports HTTP/3 out of the box.

Nicolai Parlog talks to Daniel Fuchs and Daniel Jelinski, both Consulting Members of Technical Staff at Oracle and OpenJDK committers about Java’s HTTP client. They start by briefly retracing its introduction in Java 11 and its support for HTTP/2 before diving deeper into HTTP/3 to learn about the motivation, technical underpinnings like the QUIC protocol, and challengs for its adoption before discussing its integration into Java 26.

(Apologies for the minor audio issues and thank you for your understanding.)

Links:

• JEP 517: HTTP/3 for the HTTP Client API
• Article “HTTP/3 Support in JDK 26”

Make sure to also check the Duke’s Corner podcast on dev.java.

Additional resources

• Inside.java : News and views from members of the Java team at Oracle
• Dev.java : The Destination for Java Developers
• OpenJDK
• Oracle Java

For more episodes, check out Inside Java, our YouTube playlist, and follow @Java on Twitter.

Contact us here.