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 a Quality Outreach update sent to the projects involved. To learn more about the program and how to join, please check the Quality Outreach wiki page.

Numeric Values Usage in JSON Thread Dumps

JSON thread dumps generated by com.sun.management.HotSpotDiagnosticMXBean.dumpThreads and the jcmd Thread.dump_to_file command now write thread identifiers, thread counts, and the process identifier as JSON numbers instead of strings.

For example, when using a command like jcmd <PID> Thread.dump_to_file -format=json threads.json to write thread stack traces to a file in JSON format, the output would look like in the snippet below.

{
  "threadDump": {
    "formatVersion": 2,
    "processId": 36340,
    "time": "2026-05-15T12:43:21.601545Z",
    "runtimeVersion": "27-ea+22-2010",
    "threadContainers": [
      {
        "container": "<root>",
        "parent": null,
        "owner": null,
        "threads": [
          {
            "tid": 3,
            "time": "2026-05-15T12:43:21.604046Z",
            "name": "main",
            "state": "TIMED_WAITING",
            "stack": [
              "java.base\/java.lang.Thread.sleepNanos0(Native Method)",
              "java.base\/java.lang.Thread.sleepNanos(Thread.java:562)",
              "java.base\/java.lang.Thread.sleep(Thread.java:593)",
              "HelloThreads.main(HelloThreads.java:4)",
              "java.base\/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)",
              "java.base\/java.lang.reflect.Method.invoke(Method.java:583)",
              "jdk.compiler\/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:260)",
              "jdk.compiler\/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)",
              "jdk.compiler\/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)"
            ]
          }
        ],
        "threadCount": 7
      }
      ....
    ]
  }
}

This change of format also introduces versioning through "formatVersion": 2 member, while metadata fields such as processId, tid, and threadCount are serialized as JSON numeric values rather than JSON string types.

Call to Action

We encourage you to download the JDK 27 early-access builds and test any tools, scripts, tests, or applications that parse JSON thread dumps. If needed, update them to handle numeric values for thread identifiers, thread counts, and the process identifier, and use the new formatVersion field to detect and handle future thread dump format changes.

Since JavaOne 2025, JDK 25 was released, the latest version with long-term support. But Java never stands still; it’s already time to ship JDK 26. This talk summarizes the most important changes between Java 21 and 25:

• from unnamed patterns and flexible constructors to module imports
• from the foreign-function and memory API to stream gatherers and the class-file API
• from a simpler main to launching multisource-file programs
• from Markdown in JavaDoc to quantum-resistant encryption
• from faster launch times to improved garbage collection

… before taking a closer look at the newest release, including its preview features:

• Primitive patterns and lazy constants
• Updated structured concurrency
• PEM encoding and HTTP/3 support
• New command-line options to enable deep reflection

There are plenty of features in the language, API, and runtime to discuss; whether new, improved, or finalized. Let’s go over them.

Make sure to check the JavaOne 2026 playlist.

Caching is a first-class architectural concern in agentic systems. This talk breaks down how Java applications can layer internal, distributed, and semantic caches. We’ll explore in-process caching with Caffeine for ultra-low-latency access, distributed caching with Redisson and Valkey for shared cache and semantic caching using Vector Similarity Search to reduce latency and cost while scaling LLM access.

Make sure to check the JavaOne 2026 playlist.

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 a Quality Outreach update sent to the projects involved. To learn more about the program, and how-to join, please check here.

Configure Hybrid Key Exchange Support

JEP 527 has been integrated in JDK 27 early-access builds, bringing hybrid post-quantum key exchange to TLS 1.3. This improves Java’s TLS implementation by combining traditional elliptic-curve key algorithms with quantum-resistant ML-KEM, helping protect against future harvest-now, decrypt-later threats.

Java applications that use the standard javax.net.ssl APIs can benefit by default, without code changes, as long as they do not override the TLS named groups. By default, JDK 27 enables X25519MLKEM768 alongside existing classical key exchange algorithms, so TLS clients offer both a hybrid X25519MLKEM768 key share and a traditional x25519 key share.

JDK 27 adds three hybrid key exchange options through the SunJSSE provider:

• X25519MLKEM768 is a hybrid scheme combining ECDHE with X25519 and ML-KEM-768.
• SecP256r1MLKEM768 is a hybrid scheme combining ECDHE using the secp256r1 curve with ML-KEM-768.
• SecP384r1MLKEM1024 is a hybrid scheme combining ECDHE using the secp384r1 curve with ML-KEM-1024.

You can customize the enabled groups either with the jdk.tls.namedGroups system property or programmatically via SSLParameters::setNamedGroups:

SSLSocket tlsSocket = (SSLSocket) SSLContext.getDefault()
        .getSocketFactory()
        .createSocket();

SSLParameters params = tlsSocket.getSSLParameters();

params.setNamedGroups(new String[] {
        "SecP384r1MLKEM1024",
        "X25519MLKEM768",
        "secp384r1",
        "x25519"
});

tlsSocket.setSSLParameters(params);

Call to Action

As this implementation is still new, we encourage you to download the JDK 27 early-access builds, try this feature, and share your feedback through the security-dev OpenJDK mailing list (registration required).

This session highlights the progress of JEP 528, which brings core dump and minidump support to jcmd. The jcmd tool is widely used for monitoring and troubleshooting live HotSpot JVMs. With JEP 528, jcmd will also be able to diagnose crashed JVMs, creating a more consistent troubleshooting experience across both live and post-mortem environments.

Join us for a deep dive into the future of JVM crash analysis and post-mortem diagnostics.

Make sure to check the JavaOne 2026 playlist.

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 a Quality Outreach update sent to the projects involved. To learn more about the program and how to join, please check the Quality Outreach wiki page.

Reflective Mutation of Final Fields

Java’s reflection API is a powerful meta-programming tool and a cornerstone of the ecosystem’s capabilities - without it, many important frameworks and libraries were impossible. It does not come without downsides, though. One is its ability to undermine the integrity of the keyword final, which promises that such a field is assigned exactly once, but, with reflection, that promise can be easily broken:

void main() throws Exception {
	var box = new Box("element");
	// prints "[element]"
	IO.println(box);

	var elementField = Box.class.getDeclaredField("element");
	elementField.setAccessible(true);
	elementField.set(box, "new element");

	// prints "[new element]"
	IO.println(box);
}

class Box {

	final String element;

	Box(String element) {
		this.element = element;
	}

	public String toString() {
		return "[" + element + "]";
	}

}

Final field mutation has unfortunate downstream effects where developers can’t rely on established invariants for correctness or for security, and the just-in-time compiler can’t apply all possible optimizations (particularly constant-folding). This is why recent additions to Java that deal with fields do not allow their mutation through reflection: hidden classes, records, and the preview API LazyConstant.

Integrity by Default

The characteristics of reflection follow a pattern where Java occasionally makes guarantees whose integrity can be undermined with the very tools it comes with. Of course, the application of these tools can be generally beneficial (as is the case here) but that doesn’t erase the negative impact on a project’s maintainability, security, or performance that comes from undermining Java’s integrity. There is clearly a tradeoff.

Since the additional capabilities as well as the potential downsides are ultimately borne by applications (not frameworks nor libraries), it should be their developers or operators who make the tradeoff. This is achieved by making Java stricter by default, by making it uphold the integrity of its guarantees unless specific actions are taken by application maintainers. So the various ways to undermine Java’s integrity are either replaced by features without that capability or (more often) guarded by command-line options:

• module internals are strongly encapsulated by default, but access is possible with --add-exports and --add-opens
• attaching an agent at run time leads to a warning (in the future, an error) unless allowed with -XX:+EnableDynamicAgentLoading
• calling a restricted JNI or FFM method causes a warning (in the future, an error) unless allowed with --enable-native-access
• Unsafe’s memory access methods are being removed after having been replaced by the foreign memory API

As proposed by JEP 500 and starting with JDK 26, the same is true for reflective mutation of final fields.

New Warnings and (Soon) Errors

If no new command-line options are applied, mutating a final field through the reflection API java.lang.reflect.Field::set on JDK 26 leads to a warning like the following on the standard error stream:

WARNING: Final field f in p.C has been [mutated/unreflected for mutation] by class com.foo.Bar.caller in module N (file:/path/to/foo.jar)
WARNING: Use --enable-final-field-mutation=N to avoid a warning
WARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled

This warning is emitted once per reflecting module. Consequently, if the entire application resides on the class path only one such warning is printed.

In future Java releases, this warning will become an error, at which point command-line options are required to mutate final fields through reflection.

Adapting to Immutable Final Fields

Two new command-line options are introduced that application maintainers can use to handle these warnings/errors:

• --enable-final-field-mutation is a permanent option that allows specific modules to mutate final fields
• --illegal-final-field-mutation is a temporary option with values allow, warn (default on JDK 26), debug, and deny (future default) that manages how code without specific permission that tries to mutate final fields will be handled

JEP 500 as well as Inside Java Newscast #101 discuss the use of these options as well as their interaction with strong encapsulation in detail, which is particularly important for application maintainers.

However, even given theses options, as Java moves towards a future where final fields are truly immutable by default, it is imperative for library and framework maintainers (and to a lesser degree, even application developers) to avoid mutating them through the reflection API. The article Avoiding Final Field Mutation examines various scenarios in which final fields are commonly mutated via reflection and discusses alternative approaches for each.

With JDK 27 introducing hybrid key exchange schemes that combine ML-KEM with traditional ECDHE algorithms, Java applications can gain TLS-layer protection against the “harvest-now, decrypt-later” threat without rewriting business logic.

In this episode of the Inside Java Newscast, Ana explains post-quantum hybrid key exchange for TLS 1.3 and demonstrates how a Java application can take advantage of it.

Make sure to check the show-notes.

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 a Quality Outreach update sent to the projects involved. To learn more about the program, and how-to join, please check here.

Deprecated Java Launcher Options

In Java 13, through JDK-8214731, the -Xverify:none and -noverify options were deprecated. Using either of those options currently results in bytecode verification being disabled and a warning being printed that these 2 options will be removed in the near future:

OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.

Disabling bytecode verification (which is what these 2 options do) is not recommended and the deprecation warning has been in place for several releases now, which will have given enough time for applications to stop using them.

Similarly, in Java 24, through JDK-8340244, several other java launcher options were deprecated for removal. Out of those deprecated, the following 2 are less commonly used:

• -noclassgc
• -verifyremote

Currently, when java is launched with -noclassgc, the launcher replaces its usage with -Xnoclassgc when launching the VM. A deprecation warning is also printed for this option:

Warning: -noclassgc option is deprecated and may be removed in a future release.

Similarly, when -verifyremote is used, the launcher replaces its usage with -Xverify:remote VM option and prints a deprecation warning:

Warning: -verifyremote option is deprecated and may be removed in a future release.

The deprecation warnings have been in place for some releases now and it’s time to remove support for -noclassgc, -verifyremote, -noverify, and -Xverify:none altogether.

Removal in JDK 27

Support for the options -noclassgc, -verifyremote, and -noverify will be removed from the java launcher. Support for -Xverify:none will be removed from the HotSpot VM. Using any of these options will now result in them being considered as unrecognized options and the java launcher (and the HotSpot VM) will fail with an error.

For example:

java -verifyremote -version
Unrecognized option: -verifyremote
...

The -Xverify:remote and -Xnoclassgc HotSpot VM options are untouched in this change and will continue to function normally.

For more information, please check JDK-8382727.