Welcome to the OpenJDK Quality Outreach summer update!

Everything is on track for the general availability of Java 27 on 15 September, 
as JDK 27 is now in Rampdown Phase 2, meaning that only low-risk enhancements 
may still be considered. The first release candidate builds of JDK 27 are 
expected in just over a week, once RDP2 concludes. This also means that the 
window for testing your projects with JDK 27 has almost closed. If you haven’t 
done so, now is a good time to start testing your projects using the JDK 28 
early-access builds.

Also of note, G1 is becoming the default garbage collector across all 
environments in JDK 27. Make sure to check the Heads-Up below for more details.

I’ll conclude by highlighting two non-technical resources that are nevertheless 
highly recommended: the Java documentary [1] and an episode of the Inside Java 
podcast [2] discussing JEPs and how critical they are to the evolution of the 
platform.

[1] https://inside.java/2026/07/18/the-java-documentary/
[2] https://inside.java/2026/06/25/podcast-060/


# Heads-up - JDK 27: Default G1 in All Environments

In situations where no garbage collector is specified on the command line, the 
HotSpot JVM used to select either G1 GC or Serial GC, depending on the 
environment. It preferred G1, but due to Serial's past throughput and footprint 
advantages in constrained environments, the JVM would select the latter if only 
a single CPU or less than 1792 MB of physical memory was detected.

Recent work has made G1 competitive with Serial in those environments. 
Generally speaking, G1 will have similar native memory overhead, slightly lower 
throughput, and lower maximum latencies than Serial. To make it easier to 
reason about the JVM's behavior, starting with JDK 27, it picks G1 as default 
garbage collector in all environments.

This change:

- does not remove Serial GC from the JDK, which remains available in situations 
where its performance characteristics are preferable
- does not interfere with applications that select a specific garbage collector 
on the command line
- does not interfere with applications that run in environments with multiple 
CPUs and more than 1792 MB of memory

That means an application is affected by this change only if it runs in a 
constrained environment and does not explicitly select a garbage collector. In 
such cases, we recommend benchmarking the application with different GCs to 
identify the one that best suits its needs. If that is not possible, the 
application can either use G1 as the new default or be configured to use Serial 
to ensure that its GC-related performance characteristics remain unchanged.

For more information, please check JEP 523 [3].

[3] https://openjdk.org/jeps/523


# Heads-up - JDK 28: New jlink Keystore plugin

A new `jlink` plugin has been introduced in JDK 28. It allows users to specify 
which CA certificates should be included in the `cacerts` keystore of a custom 
runtime image. This is useful for creating runtime images that contain only the 
CA certificates required by the applications that use those images. The 
command-line option accepts one or more `cacerts` keystore aliases, separated 
by commas.

For more details, see [4].

[4] https://bugs.openjdk.org/browse/JDK-8377102


# JDK 27 Early-Access Builds

The JDK 27 early-access builds for Build 32 are now available [5], along with 
the corresponding release notes [6].

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

## JEPs integrated into JDK 27:

- 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 536: JFR In-Process Data Redaction
- JEP 537: Vector API (12th Incubator)
- JEP 538: PEM Encodings of Cryptographic Objects (3rd Preview)

## Changes in recent JDK 27 builds that may be of interest:

- JDK-8381812: The synthetic $deserializeLambda$ is notably bigger [Reported by 
Eclipse Collections]
- JDK-8382582: Remove the experimental JVMCI feature
- JDK-8373426: Remove ffdhe6144 and ffdhe8192 from default list of TLS named 
groups
- JDK-8385957: JFR: Sensitive command-line arguments still in environment v…
- JDK-8381796: Enhance Certificate parsing
- JDK-8368041: Enhance TLS certificate handling
- JDK-8377833: Enhance Jar file processing
- JDK-8380672: Improve certification checking
- JDK-8360700: Implement JEP 534: Compact Object Headers by Default
- JDK-8296183: jndiprovider.properties contains properties pointing to 
non-existing classes
- JDK-8378464: PixelInterleavedSampleModel constructors and methods do not 
specify behavior …
- JDK-8374348: Implement -XX:AOTMode=required as alias for -XX:AOTMode=on
- JDK-8382031: Update IANA Language Subtag Registry to Version 2026-05-05
- JDK-8357439: Add bash autocompletion for jcmd
- JDK-8329548: Change KeyUpdate messages from TLS 1.3
- JDK-8386466: DESedeKeySpec.isParityAdjusted spec permits 8-byte key but RI 
throws InvalidKeyException

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

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


# JDK 28 Early-Access Builds

The JDK 28 early-access builds 8 are now available [8] for testing. You can 
review the Release Notes here [9].

## Changes in recent JDK 28 builds that may be of interest:

- JDK-8385957: JFR: Sensitive command-line arguments still in environment v…
- JDK-8384557: Allow configuration of the JVM's temporary directory on Linux
- JDK-8301626: Capture Named Group information in TLSHandshakeEvent
- JDK-8374058: Enhance JPEG handling
- JDK-8387123: Remove LuxTrust Global Root CA
- JDK-8386200: ListFormat incorrectly escapes single quotes
- JDK-8385834: Tighten ListFormat.getInstance(String[]) behavior for invalid 
placeholders
- JDK-8377102: New jlink plugin to specify the specific CA certificates to 
include in …
- JDK-6356745: (coll) Add PriorityQueue(Collection, Comparator)
- JDK-8385304: X25519 should utilize aarch64 intrinsics
- JDK-8380549: HttpCookie.expiryDate2DeltaSeconds returns 0 on parse failure, 
causing …
- JDK-8376748: Emit runtime warnings for JCE algorithms that will be disabled
- JDK-8386322: Float16Vector.toString should render lane values using 
Float16.toString
- JDK-8387377: Compilation is very slow when --module-path contains many 
Automatic Modules …

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

[8] https://jdk.java.net/28/
[9] https://jdk.java.net/28/release-notes
[10] https://github.com/openjdk/jdk/compare/jdk-28+0...jdk-28+7


# JavaFX 27 Early-Access Builds

The latest early-access builds of JavaFX 27 are available [11], along with the 
corresponding JavaFX 27 Javadocs [12]. These EA builds enable JavaFX developers 
to build and test their applications with JavaFX 27 on JDK 27. Although they 
are designed to work with JDK 27-ea, they are also known to work with JDK 25 
and later releases.

[11] https://jdk.java.net/javafx27/
[12] 
https://download.java.net/java/early_access/javafx27/docs/api/overview-summary.html


# Topics of Interest

- Java - The Documentary
https://inside.java/2026/07/18/the-java-documentary/

- “How JEPs Drive Java's Evolution” - Inside Java Podcast
https://inside.java/2026/06/25/podcast-060/

- “JDK 27 + Valhalla, Now!” - Inside Java Podcast
https://inside.java/2026/07/19/podcast-062/

- “Scripting JS and Python with Project Detroit” - Inside Java Podcast
https://inside.java/2026/07/09/podcast-061/

- Identifying JDK Value Class Candidate
https://mail.openjdk.org/archives/list/[email protected]/thread/Y72NRXM7KYBX43OKYBQMVKOZDWKG4MHS

- SIMD Vectors in the HotSpot JVM - Auto Vectorization and the Vector API
https://inside.java/2026/07/02/simd-vectors-hotspot-jvm/

- ZGC: A Decade of Redefining Java Performance
https://inside.java/2026/06/30/zgc-performance-decade/

- Better Tools for Immutable Data
https://inside.java/2026/06/21/better-tools-immutable-data/

- Performance Improvements in JDK 26
https://inside.java/2026/06/09/jdk-26-performance-improvements/

- Java Next Language Features
https://inside.java/2026/06/07/java-next-language-features/

- “Java *is* Memory Efficient” - Inside Java Podcast
https://inside.java/2026/05/28/podcast-059/

~


As always, if you encounter any issues while running your project on JDK 
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

Reply via email to