News

Catching Up with GraalVM: When “Faster Java” Turns into Patch Tuesday—and a Clean Break with Intel Macs

The first sign you’re behind on GraalVM isn’t a missed benchmark. It’s a build that suddenly feels… political. A CI job that used to run on an aging Intel Mac runner is starting to throw up its hands. A teammate drops a link in Slack: “macOS x64 removed.” Somewhere between your last successful Native Image build and today’s pull request, GraalVM stopped being a spicy performance side quest and started acting like infrastructure—scheduled, security-driven infrastructure.

That shift is the story of GraalVM in early 2026: a project settling into a quarterly cadence, tightening its support matrix, and—thanks to Oracle—being very explicit about what it is no longer going to be.

The release you probably missed is the one designed not to be exciting

The latest GraalVM headline is 25.0.2, released January 20, 2026, and it arrives wearing a label that tells you almost everything you need to know: it’s the January 2026 Oracle Critical Patch Update (CPU) release for both GraalVM Community Edition and Oracle GraalVM. In other words, it’s the kind of release you’re supposed to apply, not admire.

That CPU framing matters because it ties GraalVM to the same enterprise heartbeat as the rest of the Oracle ecosystem—quarterly security updates that compliance teams recognize and operations teams plan around. Oracle’s January 2026 CPU was the first quarterly drop of the year; third-party security analysis summarized it as 337 security updates addressing 158 unique CVEs across Oracle’s product families.

GraalVM 25.0.2 is built on an updated JDK baseline—25.0.2+10, per the release notes—and the emphasis is what you’d expect from a CPU release: patching vulnerabilities, fixing edge-case crashers, and smoothing over issues that show up when you run the thing in anger.

InfoQ’s January roundup treated it the way most teams will: a maintenance update that you notice mainly because it removes surprises—compiler correctness fixes, runtime stability work, the stuff that turns “native” from a demo into a dependable production target.

Then comes the part that is exciting, if you’re the one on call: Intel Macs are out

The most immediate, tactile change in the 25 line is also the bluntest: GraalVM 25 removes macOS x64 support.

This is the kind of platform decision that reads like a footnote until you remember how many developer workflows still begin on a laptop. If your team’s build scripts, signing steps, or local “does it run?” checks still happen on Intel Macs, GraalVM 25 forces a choice: migrate to Apple Silicon, shift those steps to Linux/Windows runners, or pin to an older GraalVM line and accept the long-term security and maintenance tradeoff.

Oracle’s own support matrix makes the direction unambiguous: Oracle GraalVM 25 is available for Linux and Windows on x64, and for Linux and macOS on AArch64—Apple Silicon on the Mac side.

In other words, GraalVM is following the industry’s gravity. The Intel Mac era isn’t just fading; for certain toolchains, it’s done.

GraalVM’s new superpower is predictability

If you want to understand where GraalVM is headed, don’t start with performance charts—start with the calendar.

GraalVM’s release calendar lays out a neat, almost soothing schedule: CPU releases land on the third Tuesday of January, April, July, and October, and the project even publishes planned releases for the next year. As of now, the next GraalVM Community Edition update in the 25 line is slated for April 21, 2026 (25.0.3), with follow-ons in July and October.

That kind of predictability changes the way teams “follow” GraalVM. It’s less about chasing the newest toy and more about treating GraalVM like you treat the JDK: a living dependency with a scheduled patch rhythm and a security posture you can explain in a change advisory board meeting.

The project also maintains a dedicated Vulnerability Advisories page that ties fixes to specific security-update cycles—including January 2026—giving security teams a direct breadcrumb trail from “CPU happened” to “what did we just absorb?”

The bigger pivot: Oracle decouples GraalVM from the Java release train

Underneath the tidy calendar is a messier story about identity.

In a September 2025 post with an unusually candid title—“Detaching GraalVM from the Java Ecosystem Train”—Oracle said the quiet part out loud: GraalVM for JDK 24 was the final version licensed and supported as part of Oracle Java SE products. Customers seeking patches for earlier GraalVM versions, Oracle noted, should go through My Oracle Support.

That statement doesn’t mean GraalVM is going away. It means Oracle wants it understood as a product line and platform in its own right—no longer a feature hitching a ride on Java SE’s release identity. It’s also a signal about priorities. Oracle has been increasingly explicit that the long arc of ahead-of-time compilation for mainstream Java will live in OpenJDK efforts like Project Leyden, while GraalVM’s energy expands into its polyglot ambitions.

To an enterprise buyer, this is a licensing-and-support story. To a developer, it’s a story about where innovation will show up first—and what “GraalVM news” will even mean a year from now.

Meanwhile, the ecosystem keeps building—sometimes by building downstream

If Oracle is redrawing the boundaries, the Java ecosystem is adapting, as it always does: by routing around uncertainty and packaging what developers need.

In the Quarkus world, Mandrel 25 is positioned as a downstream distribution of GraalVM 25 Community Edition, tuned specifically for Quarkus native-image workflows and aligned with OpenJDK and Red Hat Enterprise Linux libraries.

That matters because it’s a reminder that GraalVM’s influence isn’t just what Oracle ships. It’s what frameworks and platforms choose to standardize around—and how they manage the distance between upstream innovation and enterprise-friendly build pipelines.

The catch-up, distilled

So, if you’re returning to GraalVM after a few quiet months, here’s the new mental model:

GraalVM has moved into a phase where the plot is less “new native-image trick” and more “runtime you can operationalize.” The latest releases are pegged to CPU cycles. The calendar is public. Security updates have a paper trail. And the support matrix is narrowing in a way that reflects the current hardware reality—Apple Silicon in, Intel Mac out.

The irony is that this “boring” phase is often when tools become most important. When something stops being surprising, it becomes dependable. And once it’s dependable, it becomes part of the stack you’re expected to understand—even if you haven’t thought about it since the last time, you celebrated a 10x startup-time win.

About the Author

John K. Waters is the editor in chief of a number of Converge360.com sites, with a focus on high-end development, AI and future tech. He's been writing about cutting-edge technologies and culture of Silicon Valley for more than two decades, and he's written more than a dozen books. He also co-scripted the documentary film Silicon Valley: A 100 Year Renaissance, which aired on PBS.  He can be reached at [email protected].