Oracle shipped Java 27 on September 15. On the surface it looks routine: nine JEPs, no language revolution, no LTS badge. Look closer and you will find post-quantum cryptography landing silently in every TLS 1.3 handshake your application makes, by default, without touching a line of code. Alongside that: object headers shrank 33 percent, G1 GC is now on everywhere, JFR finally redacts secrets before they leave the JVM, and a decade-old interface got deleted over Amazon’s explicit objection. Java 27 is more consequential than its version number suggests.
Post-Quantum TLS Is On by Default
JEP 527 puts X25519MLKEM768 — a hybrid of classical ECDHE and NIST-standardized ML-KEM — first in Java’s TLS 1.3 named-groups preference list. If the server you are connecting to supports the hybrid, the handshake uses it automatically. No code changes, no configuration flags.
The threat this addresses is “harvest now, decrypt later”: adversaries recording your encrypted traffic today, banking on cracking it once quantum hardware matures. Java 27 closes that window proactively rather than waiting for a crisis. Most enterprises have not done this manually even on LTS releases. Java 27 does it for everyone, now.
Two caveats worth understanding. First, this only protects key exchange — certificate authentication still uses classical RSA or ECDSA, so you are not fully quantum-safe end-to-end. Second, if your code explicitly calls SSLParameters::setNamedGroups or sets the jdk.tls.namedGroups system property, your custom list overrides the default. You will need to add X25519MLKEM768 manually to opt in. Check that before assuming you are covered.
LTS users: the backport ships to JDK 17 and JDK 21 in H1 2027, and to JDK 8 and 11 in H2 2027.
Compact Object Headers: A Free Performance Win
JEP 534 makes compact object headers the default. Every object in the JVM carried a 96-bit header — 64-bit mark word plus 32-bit class pointer. That is now a single 64-bit value using a 22-bit compressed class pointer. The math is straightforward: smaller headers mean smaller heaps, more objects fit in cache, and GC does less work.
The numbers from Oracle’s JDK 27 performance report: 22 percent heap reduction and 8 percent CPU reduction on SPECjbb2015. A 15 percent drop in GC collections in a second configuration. Roughly 10 percent faster runtime in a highly parallel JSON parser benchmark. For a cloud workload running 8 GB heaps, compact headers often push that down to around 6.5 GB — real dollars saved with no developer effort.
If you hit unexpected behavior, -XX:-UseCompactObjectHeaders disables it. Oracle has flagged that escape hatch for future deprecation, so treat it as a temporary diagnostic tool, not a permanent skip.
G1 Is Now the Universal Default GC
JEP 523 ends the era of Serial GC defaulting on low-resource machines. Before Java 27, HotSpot selected Serial GC for single-CPU environments or systems with under 1,792 MB of RAM. Java 26 performance work made G1 competitive even at those resource levels, so it is now the default across the board.
Most developers running on modern cloud infrastructure will not notice. The developers who should pay attention are those running on constrained CI runners, embedded environments, or small Lambda functions where the previous Serial GC default was load-bearing behavior. Run your test suite on JDK 27 before upgrading anything in that category. Also note that G1’s heap-sizing ratios changed: MinHeapFreeRatio and MaxHeapFreeRatio moved from 40/70 to 0/100, which changes how aggressively the JVM returns memory to the OS.
JFR Finally Redacts Secrets
JEP 536 is small but overdue. Java Flight Recorder now strips environment variables and command-line arguments matching patterns like *password*, *token*, *secret*, *credential*, and *api*key* before the recording leaves the JVM. This prevents a common accidental exposure path in production diagnostics: enabling JFR to debug a latency spike and inadvertently capturing database credentials or API keys in the recording.
Redaction is on by default. If you need raw arguments for legitimate debugging purposes, the escape hatch is -XX:FlightRecorderOptions:'redact-key=none,redact-argument=none'. You can also add custom patterns or load them from a file.
JVMCI Is Gone — And Amazon Said So Publicly
The Java Virtual Machine Compiler Interface (JVMCI) has been removed after more than a decade of experimental status. JVMCI was the foundation for GraalVM’s JIT compiler, TornadoVM’s GPU execution, and several polyglot runtimes. Oracle’s rationale: it required 252 #if INCLUDE_JVMCI preprocessor blocks across HotSpot, a maintenance cost no longer justified by the number of actual users.
Amazon formally objected before the removal shipped. Their engineers cited 433 Maven Central packages that depend on GraalJS and the Truffle framework running on HotSpot. Oracle proceeded. GraalVM Community Edition has since separated from the JDK’s bundled implementation and no longer relies on JVMCI. TornadoVM replaced its dependency internally. The flags -XX:+UseGraalJIT and anything with “JVMCI” in the name are now unrecognized.
If you run GraalVM CE as a JIT replacement or depend on Truffle-based languages in HotSpot, validate your path before upgrading. For everyone else, this is a signal that the OpenJDK project is willing to make hard maintenance calls — even against enterprise pushback. That is probably healthy long-term.
Five Steps Before You Upgrade
- Compile with
--release 27without switching your runtime. This surfaces API removal issues at build time before they become runtime surprises. - Check your TLS configuration. If you set
jdk.tls.namedGroupsor callsetNamedGroups(), you are not getting post-quantum protection automatically. Add X25519MLKEM768 explicitly. - Test GC behavior on constrained environments. Any environment previously hitting the Serial GC default should be validated under G1.
- Search for
FailedException. If you use the Structured Concurrency preview API, that exception class was renamed toExecutionExceptionin this release. - Audit JVMCI dependencies. Run
mvn dependency:treeor the Gradle equivalent. If you see GraalJS, Truffle, or any JVMCI-named transitive dependency, resolve the migration before upgrading the JDK.
Java 27 is worth testing now even if you will not deploy it to production — the compact header and GC improvements feed directly into Java 29 LTS. Running your benchmark suite against JDK 27 today tells you exactly what you will gain when LTS arrives. Download it at jdk.java.net/27 and check the full release notes for the complete list of changes.













