[Jython-dev] JDK 27 Approaches Rampdown / Final Field Mutation Warnings Heads-up

[David D. <dav...@or...>]

Welcome! This is the last Quality Outreach note before JDK 27 enters Rampdown Phase One (RDP1) in early June, with the GA release planned for September. It is also worth mentioning that recent JDK 27 EA builds include fixes for issues reported by projects participating in the Quality Outreach effort, including Tomcat, Hibernate, and jOOQ. Thanks to them for their continued collaboration and testing!

I’ll conclude this brief update by encouraging everyone to review the QO heads-up below. It only takes a few minutes, but doing so can sometimes save a lot of time down the road!


# Heads-Up - JDK 27: Post-Quantum Hybrid Key Exchange for TLS 1.3

JDK 27 early-access builds now integrate JEP 527, which adds hybrid post-quantum key exchange support for TLS 1.3 to Java. This approach combines classical elliptic-curve cryptography with the quantum-resistant ML-KEM algorithm to help mitigate “harvest now, decrypt later” attacks.

By default, Java applications using the standard `javax.net.ssl` APIs will automatically negotiate hybrid post-quantum key exchange when supported by both client and server, unless the application explicitly overrides the default TLS named groups. The X25519MLKEM768 hybrid group is enabled alongside existing classical groups, while additional hybrid configurations can be controlled through `jdk.tls.namedGroups` or `SSLParameters::setNamedGroups`.

For more information, see [1].

[1] https://inside.java/2026/05/17/quality-heads-up/


# Heads-Up - JDK 27: Removal of Deprecated Java Launcher Options

Support for the options `-noclassgc`, `-verifyremote`, `-Xverify:none`, and `-noverify`, which were deprecated several releases ago, is removed from the Java launcher in JDK 27, and usage of any of these options will fail with an error.

In the case of the former two, `-Xnoclassgc` and `-Xverify:remote` should be used instead. No alternative is being provided for `-Xverify:none` and `-noverify`, as disabling bytecode verification (which is what these two options do) is not recommended.

For more information, see [2].

[2] https://inside.java/2026/05/13/quality-heads-up/


# Heads-Up - JDK 26: Final Field Mutation Warnings

Java's reflection API allows the mutation of final fields outside of construction. This undermines the integrity of the language, which promises exactly-once semantics for final field assignment. This, in turn, has negative downstream effects for integrity, performance, and security.

With JDK 26, Java has moved toward “integrity by default” for final fields, with the JVM now emitting warnings when code attempts to mutate final fields reflectively. These new warnings can be disabled using command-line options. The permanent option `--enable-final-field-mutation` allows specific modules to mutate final fields. The temporary option `--illegal-final-field-mutation`, with values `warn` (the default in JDK 26), `allow`, `debug`, or `deny` (the future default), controls how code without specific permission attempting to mutate final fields will be handled.

For more information, see [3] and [4].

[3] https://inside.java/2026/05/15/quality-heads-up/
[4] https://inside.java/2026/04/27/avoiding-final-field-mutation/


# JDK 27 Early-Access Builds

The latest JDK 27 early-access builds are available[5], along with the corresponding Release Notes[6].

[5] https://jdk.java.net/27/
[6] https://jdk.java.net/27/release-notes

## JEPs targeted to JDK 27, so far:
- JEP 523: Make G1 the Default Garbage Collector in All Environments
- JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
- JEP 531: Lazy Constants (3rd Preview)
- JEP 532: Primitive Types in Patterns, instanceof, and switch (5th Preview)
- JEP 533: Structured Concurrency (7th Preview)
- JEP 534: Compact Object Headers by Default
- JEP 537: Vector API (12th Incubator)

## JEPs proposed to target JDK 27:
- JEP 528: Post-Mortem Crash Analysis with jcmd
- JPE 536: JFR In-Process Data Redaction
- JEP 538: PEM Encodings of Cryptographic Objects

## Changes in recent JDK 27 builds that may be of interest:
- JDK-8273874: LdapClient can trigger memory leak [Reported by Apache Tomcat]
- JDK-8371817: javac with annotation processor throws AE: Cannot add metadata to this type: METHOD when dealing with local classes [Reported by Hibernate]
- JDK-8305250: Unnecessary "unknown enum constant" warning emitted by javac when dependency has optional annotations with enums [Reported by JOOQ]
- JDK-8368864: Confusing error message (or wrong error) when record component has @deprecated Javadoc tag [Reported by JOOQ]
- JDK-8381670: Revert the changes to GZIPInputStream related to InputStream.available() usage
- JDK-8372351: Add 2 WISeKey roots
- JDK-8371842: Update CLDR to Version 48.2
- JDK-8373481: Remove the deprecated -noclassgc, -noverify, -Xverify:none and -verifyremote options from the java launcher
- JDK-8372526: Add support for ZLIB TLS Certificate Compression
- JDK-8382740: JFR: Disable jdk.OldObjectSample event for generational ZGC
- JDK-8381436: Remove Obsolete Translation Resources
- JDK-8364182: Add jcmd VM.security_properties command
- JDK-8369917: LMS/HSS RFC 9858 Support
- JDK-8196182: ServiceLoader.iterator().hasNext()/.next() may throw a LinkageError
- JDK-8378228: Replace jQuery UI autocomplete component in JavaDoc search
- JDK-8347112: Copy nested directories in doc-files by default
- JDK-8379973: Provide means to customize localized patterns in DateTimeFormatter/Builder
- JDK-8383175: (tz) Update Timezone Data to 2026b
- JDK-8380542: ZipOutputStream.setComment and ZipEntry.setComment spec updates for rejecting unmappable characters and allowing null or empty comments
- JDK-8373922: Enhance Taglet API to support relative URLs
- JDK-8374839: Improve jpackage information messages

Note: A more exhaustive list of changes can be found here[7].

[7] https://github.com/openjdk/jdk/compare/jdk-27+17...jdk-27+22


# JavaFX Direct3D 12 Early-Access Builds

New early-access JavaFX builds implementing the new Direct3D 12 graphics rendering pipeline for Windows x64 are now available[8].  The goal of this EA builds is to solicit feedback as we work toward integrating this functionality into JavaFX. Feedback can be sent to the openjfx-dev[9] mailing list (registration required).

[8] https://jdk.java.net/javafxdirect3d12/
[9] https://mail.openjdk.org/mailman/listinfo/openjfx-dev


# Topics of Interest

- Ask the Architects at JavaOne
https://inside.java/2026/04/23/podcast-056/

- How the JVM Optimizes Generic Code
https://inside.java/2026/04/19/generics-optimization/

- Java 26: Better Language, Better APIs, Better Runtime
https://inside.java/2026/05/19/javaone-better-jdk26/

- Post-Mortem JVM Crash Analysis with jcmd
https://inside.java/2026/05/16/javaone-jcmd-jvm-analysis/

- Java Gets Post-Quantum TLS
https://inside.java/2026/05/14/newscast-112/

- The JDK Client Desktop: 2026 and Still Swinging
https://inside.java/2026/05/03/jdk-client-desktop/

- Make Java Safer with Flexible Constructor Bodies
https://inside.java/2026/04/30/newscast-111/

- Avoiding Final Field Mutation
https://inside.java/2026/04/27/avoiding-final-field-mutation/

- How JDK 26 Improves G1's Throughput
https://inside.java/2026/04/09/podcast-054/

- JavaOne 2026 Playlist (Continuously updated)
https://www.youtube.com/playlist?list=PLX8CzqL3ArzUMVSzm-z_-if8BIB55EGl4

~


As always, if you encounter any issues while running your project on JDK 27 early-access builds, please feel free to reach out.

P.S. If you would prefer not to receive future OpenJDK Quality Outreach updates, just let me know.

—David