Shiwen Talks Episode 16 | Java 27 Released: In the Age of AI-Written Code, What Is This Old Language Busy With?

Opening: A quiet email, and a nearly thirty-year-old language’s routine half-year homework

On September 15, OpenJDK chief engineer Mark Reinhold sent a short message to the announce mailing list: JDK 27 is officially GA, build 35. From the RC2 on August 20 to the final release, not a single P1-level bug appeared. The GPLv2-licensed OpenJDK build was available for download that same day at jdk.java.net/27. In 2026, when AI programming tools update almost weekly, this nearly thirty-year-old language hands in its homework every six months as usual—this time with only 9 JEPs, no blockbuster new syntax, as quiet as a routine maintenance release.

But the details are worth savoring. Among the 9 JEPs, the two things that most directly impact users’ wallets happen to not be syntax at all: G1 garbage collector becomes the default across all environments (JEP 523), and compact object headers are enabled by default (JEP 534)—both about saving memory. At the same time, post-quantum hybrid key exchange entered TLS 1.3 (JEP 527), a change clearly prepared for a decade from now. On the other side, primitive type pattern matching is on its 5th preview, structured concurrency on its 7th preview, and the Vector API has reached its 12th incubator version—some call this rigor, others call it sluggishness.

Shiwen: In an age where AI writes code at lightning speed, Java released a version like this—what’s your first reaction?

Yongliang: Not “Is Java still relevant,” but “These two things are finally set as defaults.” Memory-saving changes move me more than new syntax—I manage technology at a hospital group in Tianjin with hundreds of JVM services; shrink the heap by a fraction, and the bill slims down too. As for how many rounds the previews have been through, let’s take our time and talk it through.

Shiwen: Then let’s talk it through: whether writing Java in the AI programming era is being conservative, whether the preview marathon is rigor or sluggishness, why the two default settings are the most important things in this release, why AI companies don’t talk about post-quantum groundwork, and three practical pieces of advice for those staying in the Java ecosystem.

Q1: In the AI programming era, is still writing Java being conservative?

Yongliang: It’s not conservatism, it’s division of labor. The faster AI writes code, the harder the machines running that code have to work, and what Java has accumulated over thirty years is precisely the foundation that “keeps code from breaking.”

AI tools have raised the speed of writing code by an order of magnitude. More than half the people on my team use AI to write code—there’s no avoiding that. But there’s a fact that’s often overlooked: the more AI writes, the harder the machines running that code have to work. Generated code doesn’t run itself; it takes up memory, needs garbage collection, and has to hold up against scheduled tasks at two in the morning. I work at a hospital group in Tianjin—registration, billing, lab results—these systems mostly run on the JVM, and many of them have been alive longer than most AI companies have existed. Java’s value has never been about whether its syntax is new—honestly, its syntax has always been in the “adequate but not pretty” category—but about the runtime foundation built up over thirty years: mature garbage collectors, observability tools you can analyze line by line, and a community where you search for a problem and find an answer. So the question “Is writing Java in the AI programming era being conservative?” is asking the wrong thing. The real division of labor is: AI is responsible for writing the code, the JVM is responsible for keeping the code from breaking. The barrier to writing code is going down; the barrier to keeping systems from breaking has never gone down. For a system that needs to run for fifteen years, “conservative” is sometimes just another name for “reliable.”

Q2: One feature previewed five times, one concurrency mechanism refined over seven rounds, one API incubated through twelve versions—is this rigor or sluggishness?

Yongliang: This is Java and the AI industry betting on two different things. AI bets on “ship first, fix later”; Java bets on “the cost of getting it wrong is far greater than the cost of being late.” Both bets are correct, provided you can afford to lose.

Let’s start with the stakes on each side. The AI industry bets on “ship first, fix later”: the cost of a conversational product making a mistake is one bad answer—close and reopen, and it’s behind you. So weekly or even daily updates make sense. Java bets in the other direction: once a language specification is finalized, it’s permanent. Type erasure for generics has been raised for over twenty years and still hasn’t been fixed; the checked exceptions debate has been argued since JDK 5 and is still going. For a decision you can’t take back, spending a few extra years refining it is rational, not procrastination. Moreover, the “preview” mechanism itself is a counter to sluggishness—it lets millions of production-environment users try features in earnest before they’re finalized, with feedback directly shaping the spec. Structured concurrency went from version 1 to version 7, and what got fixed along the way was exactly the pitfalls real users stumbled into. Of course, the cost is real: primitive type pattern matching, which you want this year, will still need a few more versions before it’s finalized. My attitude is straightforward: if you’re a startup, this pace will suffocate you—don’t force it; if you’re maintaining a system that needs to survive fifteen years, you’ll be grateful someone was slow for you—a feature arriving three years late is a better deal than a mistake following you for life.

Q3: Why are the most important things in this release not new syntax, but two “memory-saving” defaults?

Yongliang: Because the real pain point for enterprises is on the bill, not in the syntax. Of the 9 JEPs, the two that most directly hit the wallet happen to both be about saving memory—this is no coincidence; it’s determined by this language’s user profile.

Let’s look at the version structure first. Java 25 was last September’s LTS release; 27 is non-LTS, and the next LTS is expected to be JDK 29. For enterprises, large-scale upgrades only happen on LTS releases, so most of the new features in 27 won’t truly be used in production until 29. So why is 27 important? Because it turns two memory-saving things into default behavior. First, G1 becomes the default garbage collector across all environments—previously, choosing a GC was a technical decision that needed justification; now there’s no need to choose, and large-heap services get a pause-time-targeted collector out of the box. Second, compact object headers are enabled by default, significantly reducing the per-object header memory overhead in Java. Neither of these features is sexy, but what they directly change is the bill: a hospital group running hundreds of JVM services, with heap usage shrinking by a tenth (this is my personal estimate, not an official figure), saves real money on memory procurement and cloud costs. Syntax sugar makes developers happy; smaller heaps make finance happy. After spending enough time in enterprises, you come to understand: a reason that can be written into a procurement request is worth far more than a reason that can be written into a press release.

Q4: Post-quantum key exchange enters TLS 1.3—an established language is laying groundwork for a decade from now; why do AI companies rarely talk about this?

Yongliang: Because the two sides’ customers price “a decade from now” completely differently. Hospital data needs to be stored for decades; the “store now, decrypt later” threat is happening today. But most AI products have a data lifecycle under two years—the lock hasn’t even rusted yet, and the product is already offline.

What JEP 527 does is use both a traditional algorithm and a quantum-resistant algorithm to compute a key during the TLS 1.3 handshake, so that neither side being compromised is fatal. Why do this now? Because the “store now, wait for quantum computers to mature, then decrypt” attack is happening today: attackers intercept your current encrypted traffic and store it, then pick the lock ten years later. Medical data retention periods are measured in decades; a single handshake in today’s registration system might still have legal significance in the 2040s—so for hospitals, this is a risk being billed right now, not a story about a decade from now. Meanwhile, most AI startups have data lifecycles under two years; training sets change every few months, and products go offline before the lock even rusts—so naturally no one is rushing to talk about changing locks. This isn’t about who’s better or worse; it’s about different time scales: the users of established languages are budgeting for 2040, while the AI industry’s customers are betting on whether they’ll still exist in six months—each side is rational, and neither needs to mock the other.

Q5: Three practical pieces of advice for those still in the Java ecosystem

Yongliang: Three, in order: only upgrade to LTS in production, treat memory savings as a serious metric, and let AI write code but don’t let AI make architecture decisions for you.

First: in production environments, only upgrade to LTS—don’t chase the new. Java 25 is the current LTS; 27 can be used for trying, for reading, for serving as your team’s technology radar, but don’t put it in production. The next LTS is expected to be JDK 29—by then, take in the mature parts of both 27 and 29 together. Version anxiety is a non-issue in this ecosystem; the real risk is compatibility incidents caused by chasing the new. Second: treat memory savings as a serious metric to manage. After compact object headers are enabled by default, spend a week comparing heap usage across your core services (this is estimation-level work, but the direction won’t be wrong), and convert the saved memory into money and write it into your quarterly summary—letting your boss see the return on JVM tuning is more useful than writing ten technical articles. Third: let AI write code, but don’t let AI make architecture decisions. AI-generated code is increasing, but decisions like which dependencies to choose, how to split services, and how data flows—these decisions have impact measured in years, and humans must bear them. Structured concurrency has been refined through its 7th preview and still isn’t finalized, which shows exactly how hard concurrency-model decisions are—so hard that it takes seven rounds of public refinement before they dare to finalize it. I’ve worked in software for seventeen years and led a team of seventy; the most expensive pitfalls I’ve stepped into were all architecture decisions where “at the time it seemed like we could just do it this way for now”—not a single one was a syntax mistake.

Epilogue

Shiwen: Finally, summarize this episode in one sentence?

Yongliang: AI determines how fast code gets written; the JVM determines how stably the system runs—in an era where code gets written faster and faster, stability itself is a competitive advantage.

Shiwen: That line goes out to everyone. See you next time.

[Technical Deep Dive] The overhead in object headers you never wrote—how G1 and compact object headers team up to save it

This episode’s main thread is “saving memory is closer to real enterprise pain points than new syntax.” For readers who want to go one layer deeper, let’s break it down: why do two unremarkable default settings deserve the two most important spots in JDK 27?

Layer one: what’s in an object header. In Java, every object carries a header in addition to the fields you write: a mark word recording the hash code, lock state, and GC marks, plus a pointer to class metadata. You never wrote a single line of code for this information, but every object carries it.

Layer two: why this overhead is significant. On a 64-bit machine with compressed pointers enabled by default, an object header typically takes 12 bytes—the smaller the object, the higher the header’s proportion. An object holding just two integers has 8 bytes of data and 12 bytes of header—more than half the memory goes to “luggage.” For services with millions of small objects in the application (caches, sessions, message queues are all hard-hit areas), the bulk of the heap isn’t data—it’s luggage.

Layer three: how the two JEPs team up to save. Compact object headers (JEP 534, enabled by default in this release) re-encode the header information, significantly compressing this overhead; G1 (JEP 523, becoming the default across all environments) slices the heap into regions and collects based on pause-time targets, so large-heap services no longer need to agonize over choosing a collector. One makes each object leaner; the other makes whole-heap management smoother.

Back to this episode’s main thread: new syntax solves “how enjoyable it is to write code”; object headers and garbage collectors solve “how much the bill hurts.” For enterprises, the pain is never on the keyboard.

Sources for this episode

OpenJDK announce mailing list, 2026-09-15: Mark Reinhold, “JDK 27 General Availability” (build 35, with the list of 9 JEPs)
jdk.java.net/27 (GPLv2-licensed OpenJDK build download)
OpenJDK’s semi-annual release cadence and LTS naming conventions (as of 2026-09-16; the next LTS is expected to be JDK 29)