JDK 27 Released: G1 GC Is Now the Default, Compact Object Headers & Post-Quantum TLS — Should You Upgrade?

By -

On September 15, 2026, JDK 27 reached general availability — the 18th feature release in a row to ship on Java's six-month cadence. It carries nine JEPs, but the headline is not the count. It is this: JDK 27 is the release where Java stops asking you to opt in to good defaults and turns them on. Two of the four finalized JEPs quietly change how your running services behave without you touching a line of code — and a third hardens every TLS connection your apps make against quantum computers.

If your services run in small containers and you never set a GC flag, this release changes your garbage collector. Read on before you bump the base image.

The release at a glance

Four JEPs are final and active with no special flags; the rest stay in preview or incubator, meaning their APIs can still change:

JEPFeatureStatus
523Make G1 the default garbage collector in all environmentsFinal
527Post-quantum hybrid key exchange for TLS 1.3Final
534Compact object headers by defaultFinal
536JFR in-process data redactionFinal
531Lazy constants3rd preview
532Primitive types in patterns, instanceof, and switch5th preview
533Structured concurrency7th preview
537Vector API12th incubator
538PEM encodings of cryptographic objects3rd preview

First, what JDK 27 isn't: it is a short-term, non-LTS feature release with six months of Oracle support. JDK 25 remains the current LTS (the release most production teams should standardize on), and the next LTS is not due until JDK 29 in September 2027. If you are still deciding where your estate should live, see Oracle JDK 21's Free Updates Ended: What Java Teams Must Do first.

The change that matters most: G1 everywhere (JEP 523)

G1 has been the default collector on "server-class" machines since JDK 9. But there was always a carve-out: when the JVM saw a single CPU or less than ~1.8 GB of heap, it silently picked the Serial collector instead. That rule caught a lot of teams out in containers, where a tiny CPU quota could flip your app to Serial GC without anyone noticing.

JEP 523 removes that ergonomic special case. If you do not name a collector on the command line, you get G1 — on any hardware, any heap size. The reasoning, per the JEP, is that years of G1 improvements (including the throughput work that landed in JDK 26) closed the gap that once justified Serial on small machines.

JDK 26 and earlier JDK 27 (JEP 523) JVM starts, no -XX GC flag set 1 CPU or heap < ~1.8 GB? yes no Serial GC G1 GC JVM starts, no -XX GC flag set G1 GC — always no carve-outs -XX:+UseSerialGC still wins if set explicitly An explicitly chosen collector always wins — on both sides. Diagram: default GC selection with no -XX flag. Illustrative.

The practical takeaway: if you run small containers and never set a GC flag, your GC behavior changes the moment you upgrade. G1 is very likely better — but "very likely" is not a measurement. Watch memory footprint and pause times on your smallest deployments first.

Smaller objects for free (JEP 534)

Compact object headers shrink the object header from 96 bits to 64 bits on 64-bit architectures, which reduces heap size, improves deployment density, and increases data locality. The feature was experimental in JDK 24 and opt-in in JDK 25; in JDK 27 it is simply on. Applications with large numbers of objects benefit most — and on the Java side, that is nearly every Spring Boot service ever written. (JetBrains reports consistent memory savings with it enabled in their own IDEs.)

Post-quantum TLS by default (JEP 527)

JEP 527 adds hybrid post-quantum key exchange to TLS 1.3 and turns it on by default. The threat it addresses is "harvest now, decrypt later": an adversary records your encrypted traffic today and decrypts it once quantum computers are powerful enough. With hybrid key exchange, that recorded traffic stays protected even then — with zero code changes, as long as you have not hard-coded specific key-exchange groups.

This is the change most likely to surprise someone: if any of your integrations pin TLS parameters or run through legacy middleboxes that choke on unfamiliar handshake groups, you want to find that out in staging, not production. Test TLS to every external and legacy internal system.

Also final: JFR in-process data redaction (JEP 536)

Java Flight Recorder gains in-process redaction of sensitive data. If you record production flights — and you should, they are the cheapest production telemetry you have — this makes it safer to keep recordings that pass through card numbers, tokens, or PII. Check the current JDK docs for the exact redaction controls before relying on them.

Worked example: find out what your JVM actually picked

Do not trust the default you remember. Ask the JVM. On any machine or container running JDK 27:

java -Xlog:gc -version

The log line tells you which collector the JVM selected — on JDK 27 with no flags, expect G1. To see the effective flag values:

java -XX:+PrintFlagsFinal -version | grep -E "UseG1GC|UseSerialGC|UseCompactObjectHeaders"

Illustrative output on a stock JDK 27 (your exact build's values may differ — verify against your own install):

     bool UseCompactObjectHeaders                    = true      bool UseG1GC                                   = true      bool UseSerialGC                               = false

Now run the same two commands on your current JDK inside your smallest container. If you see UseSerialGC = true there and UseG1GC = true on 27, you have found a service whose GC behavior will change on upgrade — put it at the top of the staging list.

If a tiny sidecar or CLI tool genuinely runs better on Serial, opt back explicitly. An explicit choice always wins:

# Default on JDK 27, any hardware: G1
java -jar app.jar

# Explicitly opt back into Serial
java -XX:+UseSerialGC -jar app.jar

The upgrade checklist

  1. Run your test suite on JDK 27 in CI alongside your current version. Green on your current JDK proves nothing about the new defaults.
  2. Check your actual GC with -Xlog:gc or PrintFlagsFinal — especially in small containers, where the old Serial carve-out used to bite.
  3. Compare memory before and after. Compact headers should shrink heap usage; confirm it on your workload rather than assuming the headline number applies to you.
  4. Test TLS connections to all external and legacy internal systems — post-quantum hybrid key exchange is on by default and legacy middleboxes are the risk.
  5. Review how secrets reach the JVM. JFR redaction helps, but avoid command-line secrets regardless.
  6. Set explicit JVM flags for anything you depend on — GC choice, heap sizing — instead of relying on defaults that just proved they can move under you.

Should you upgrade?

For production: probably not yet — and that is fine. JDK 27 is a short-term release with six months of support; JDK 25 LTS is where production should live. The recommendation from the upgrade guides is the right one: add JDK 27 to your CI pipeline now, even if production stays on 25. The new defaults — G1 everywhere, compact headers — are very likely to land in the next LTS (JDK 29, due September 2027). Testing them today turns your next LTS upgrade from a surprise into a routine.

For memory-hungry services, the heap savings from compact headers alone may justify moving to 27 sooner — but measure first, on your workload, in staging.

Bottom line: JDK 27 changes your app without you touching the code. Four defaults flip the moment you upgrade: your collector, your object headers, your TLS key exchange, and your JFR redaction. None of them is scary — all of them deserve a measurement. Put 27 in CI this week, and let the numbers decide.

Version-sensitive details (exact flag names, TLS group behavior) can shift between builds — check the current JDK documentation for your build before relying on them.

.

Comments

Post a Comment

Popular posts from this blog

JSP Servlet Interview Questions For Freshers Series 1

By -
Image
We know that while preparing for an interview there are lots of things needs to keep in your mind, and for freshers not easy to cover all the questions of Core Java, Servlet, JSP, Database, Aptitude, Algorithm etc. So we have planned to design few very popular interview question askeds in an interview for freshers on different series based on there priority and of course priority start from series 1. In our previous post we have listed very popular 20 Core Java basic interview questions for freshers . Friends don't worry we will post maximum number of interview questions on JSP Servlet but, started from very popular and most respective questions. JSP Servlet Interview Questions For Freshers Series 1 1. What is the life cycle of Servlet? Yes, this is very popular interview question and interviewer expect from you to at least list down the process involved while serving request for a Servlet. Well, Servlet life cycle is managed by Servlet Container and javax.servlet.Servlet in...
Read more

What are the core classes and interfaces of hibernate 4

By -
Hibernate is an Open source Object Relational Mapping framework. It enables developer to develop classes to be persist in an object oriented way including inheritance and the Java collections framework. Current hibernate stable release is 4.3.5 that was released in April 2014. It has various classes and interfaces, but sometimes interviewer ask you to list down the core classes and interfaces of hibernate. Well hibernate has various classes and interfaces, but when we say core classes and interfaces those are listed below, they all are the exceptional role in hibernate library. Configuration (class) ServiceRegistry (interface) SessionFactory (interface) Session (interface) Transaction (interface) Query (interface) Configuration: Is a class resides inside the org.hibernate.cfg package. Configuration as it's name implies it is all about the configuration of the application, configuration of the application done only at the initialization time which is only once for t...
Read more

Java Banking Finance Services and Insurance (BFSI) domain interview questions

By -
Image
Banking, Financial Services and Insurance ( BFSI ) is a banking domain, nowadays in IT industry high pay, stability and most respected domain after R&D, which includes verity of products and services such as commercial banks, insurance companies, non-banking financial companies, cooperatives, pensions funds, mutual funds etc. In BFSI domain mostly questions are comes from the Class loader, Thread, Concurrency api, Array, Collection, JVM architecture, Java Memory Model, String pool, String, StringBuilder, StringBuffer, and Puzzle. Normally interviewer will ask you to rate yourself in the above given API's, it is again depends on interviewer state of mind. Interviewer: Ok lets start with Collection, What is the different between ArrayList and LinkedList ? The demand of this question is to just make you comfort while in a interview ground. Smart Candidate :) ArrayList and LinkedList both are implementation of List interface. ArrayList implementation is based on dyna...
Read more