JDK 27 arrives in September with G1 as default and nine JEPs; JDK 28 already has a JSON API on the radar

JDK 27 has reached its first release candidate, according to an announcement by Mark Reinhold, chief architect of the Java Platform Group at Oracle. It is the second non-LTS version since JDK 25, and the feature set is already frozen: the main repository was forked into the stabilization repository in early June 2026 (Rampdown Phase One). From that point on, only critical bug fixes approved through the Fix-Request process are allowed in. The formal release is scheduled for September 15, 2026, with JDK 28 expected for March 2027.

For those who build and maintain Java systems in production in Brazil, the practical point is the six-month cadence between releases. Since JDK 27 is non-LTS, most companies will keep running JDK 25 (LTS) in production, but the feature list gives plenty of advance notice of what will be consolidated in the next LTS. It's worth following the roadmap to avoid being caught off guard during migration.

What's in JDK 27

There are nine JEPs in total, spread across four categories. Two HotSpot changes are the ones that most affect those already running Java in production, since they apply by default, without a flag.

JEP 523: G1 as the default garbage collector across all environments. Until now, G1 was the default only in server environments. With this change, if no GC is specified on the command line, HotSpot will always choose G1, including in smaller environments. In practice, this is a standardization of behavior that reduces tuning surprises across different machines.

JEP 534: Compact Object Headers by default. The compact headers feature was delivered in JDK 25 (JEP 519) as an option; it now becomes the default object header layout in the JVM. Smaller headers mean lower memory consumption per object, which translates into a smaller heap footprint in applications with many live objects, a common scenario in high-throughput services.

JEP 536: JFR In-Process Data Redaction. JDK Flight Recorder can now redact sensitive information before finalizing a recording, such as command-line arguments, initial environment variable values, and system properties. This is relevant for those who collect JFR recordings in production and need to avoid leaking secrets in diagnostic artifacts.

Previews that keep moving forward

Much of what's new is still in preview or incubation, tied to OpenJDK's major projects:

• JEP 532 (Project Amber), Primitive Types in Patterns, instanceof, and switch (fifth preview): extends pattern matching to primitive types across all pattern contexts, and expands instanceof and switch to work with all primitives. This preview brings a refined definition of "unconditional exactness" and stricter dominance checks in switch.
• JEP 533 (Project Loom), Structured Concurrency (seventh preview): treats groups of related tasks running on different threads as a single unit of work, simplifying error handling, cancellation, and observability.
• JEP 537 (Project Panama), Vector API (12th incubator): no substantial implementation changes since JDK 25. The API will remain in incubation until the necessary Project Valhalla features are available as preview.
• JEP 531, Lazy Constants (third preview) and JEP 538, PEM Encodings of Cryptographic Objects (third preview).

A security highlight is JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3, which adds a quantum-resistant hybrid key exchange to TLS 1.3. For Brazilian teams operating under regulatory cryptography requirements (financial sector, healthcare, government), it's a sign that the platform is already moving in the post-quantum direction.

What's already on JDK 28's radar

JDK 28, with GA expected for March 2027, already has six JEPs (five Targeted and one Proposed to Target). Here are some points worth watching for planning purposes:

• JEP 540, Simple JSON API (Incubator): defines a standard API for parsing and generating JSON documents without relying on an external library, implementing RFC 8259. It replaces the old JEP 198 (Light-Weight JSON API), now closed. For the Brazilian ecosystem, heavily dependent on Jackson and Gson, this is a development worth following, still in incubation, but with the potential to reduce dependencies in simple cases.
• JEP 401, Value Objects (Preview): part of Project Valhalla, this proposes value objects, defined as objects that only contain final fields, have no identity, and are distinguished solely by the values of their fields. It's one of the platform's most anticipated structural changes.
• JEP 539, Strict Field Initialization in the JVM (Preview): introduces strictly initialized fields in the JVM, which must be initialized before being read, so that default values such as 0 or null are never observed.
• JEP 535, Shenandoah GC: Generational Mode by Default: makes generational mode the default for Shenandoah, deprecating non-generational mode.
• JEP 541, Deprecate the macOS/x64 Port for Removal: deprecates the macOS/x64 port for future removal, since Apple no longer supports this architecture, following the same maintenance cost-cutting logic already applied to the Windows 32-bit x86 port (JEP 449).
• JEP 542, PEM Encodings of Cryptographic Objects: a proposal to finalize the feature after three rounds of preview (JDK 25 through 27).

Among the drafts that could still make it in are Lazy Constants (fourth preview) and Faster Startup and Warmup with ZGC, which proposes allocating memory more efficiently based on the application's needs, creating a small initial heap to reduce operating system overhead and improve startup time.

What remains open

Draft JEPs, as InfoQ points out, can change at any time, and Oracle is expected to target additional JEPs for JDK 28 soon. In other words, the JDK 28 list is not yet finalized. JDK 27, on the other hand, being in release candidate, has its feature set practically defined, with only critical fixes remaining until September 15. For teams planning upgrades, the message is clear: G1 and compact headers become the default now, and medium-term architectural bets (value objects, structured concurrency, Vector API) continue maturing release after release.