JDK 25 Is the Last Java LTS for Intel Macs

Java is done with Intel Macs. JEP 541 deprecates the macOS/x64 port for removal, and Oracle's engineers stop maintaining it as of JDK 27, due in September 2026. Once the JEP lands, configure on an Intel Mac errors out unless you pass --enable-deprecated-ports, and even then Oracle's position is blunt: no guarantee the port builds, much less works. Removal will follow in a later release.

If you know how OpenJDK retires platforms, you know the deprecation is the news, not the removal. Solaris/SPARC was deprecated in JDK 14 and gone in 15. The 32-bit Windows port was deprecated in JDK 21 and deleted in 24; generic 32-bit x86 was deprecated in 24 and gone by 25. The gap between "deprecated for removal" and "removed" is usually one or two releases, and nothing about this port suggests it'll get a longer goodbye. Plan as if mainline OpenJDK loses macOS/x64 sometime in 2027.

Oracle is actually the patient one here

The tempting read is "Oracle abandons Intel Macs," but the timeline says the opposite. Apple sold its last Intel Mac in mid-2023. macOS 26 Tahoe is the final release that boots on Intel hardware at all, and it supports only a handful of 2019–2020 models. Rosetta 2, the x86-on-ARM translation layer, sticks around through macOS 27 and then shrinks to a compatibility shim for old games. Meanwhile the JDK 25 LTS line — the last one with a macOS/x64 build — carries Oracle premier support into 2030 and extended support beyond that.

Run the clocks side by side and your Intel Mac loses macOS security updates before it loses Java updates. By the standards of the ecosystem, that's generous: Rust demoted x86_64-apple-darwin to Tier 2 last year, and Node.js plans to mark the platform experimental. OpenJDK held Tier 1-style treatment longer than most, on a platform whose remaining test hardware literally cannot be purchased new.

There's also a structural point worth naming. Every port OpenJDK carries is a tax on every feature that touches the runtime's guts — Project Loom's continuations, the FFM API, ZGC's barriers all need per-platform assembly and per-platform CI. The macOS/AArch64 port (JEP 391, JDK 17) took over as the real Mac platform years ago. Keeping a zombie port alive slows the work that actually matters, which is why the JEP frames this purely as maintenance cost.

Who actually gets hurt

For most developers this is a shrug. If you're on an M-series Mac — which, five years into the transition, is nearly everyone writing Java on a Mac — nothing changes. The groups that need a plan are more specific:

Teams still developing on Intel MacBooks. Your ceiling is JDK 25. That's a real LTS with years of runway, and Eclipse Temurin, Azul Zulu, and Amazon Corretto will keep shipping macOS/x64 builds of the LTS lines for as long as their support windows run. Pin 25, stop tracking the six-month train, and treat the hardware refresh as the actual fix. If the machine must see newer JDKs, Linux on the same hardware remains a fully supported x64 platform.

Intel-based macOS CI. If your pipeline still runs on Intel Mac minis in a rack — or on the last x64 macOS images your CI vendor offers — the writing has been on the wall since GitHub's macos-latest runners went Apple Silicon. Migrate the runners now, and keep one JDK 25/x64 job only if you genuinely ship to Intel Mac users.

The Rosetta crowd — the trap nobody's pricing in. A quiet contingent runs an x64 JDK on Apple Silicon via Rosetta 2, usually because some JNI dependency — an old native driver, a vendor .dylib, an x64-only agent — never got an arm64 build. This workflow dies twice: the x64 JDK stops advancing past 25, and Rosetta itself sunsets after macOS 27. If you're in this bucket, the JDK deprecation is your forcing function to replace that native dependency, and you have roughly two years, not five.

Desktop Java vendors. If you ship a Mac app with a bundled runtime via jpackage, your Intel .dmg is now frozen on the 25 line. Given Tahoe is those users' terminal macOS anyway, the defensible move is shipping arm64-only for new versions and maintaining a security-patch-only x64 build until your telemetry says stop.

The subtler risk is ecosystem attrition, which historically outpaces the JDK itself. Once mainline drops a platform, library maintainers stop cross-compiling native artifacts for it — watch for netty, sqlite-jdbc, and friends to quietly drop osx-x86_64 classifiers from their jars. Your JDK 25 install will keep working; your dependency upgrades are what break.

The right call, made at the right speed

JEP 541 includes the standard escape hatch: if credible maintainers step up, the deprecation can be reverted before removal. Nobody should expect that. Solaris had vocal defenders and corporate history behind it; Intel Macs have a fixed, shrinking installed base and a vendor actively demolishing the platform underneath them. There is no constituency that wants this port more than Apple wants it gone.

So call it what it is: a well-telegraphed, correctly sequenced platform retirement, with a longer support tail than Apple itself is offering. The genuine deadline hiding in it isn't September 2026 — it's that JDK 25 is the last Java LTS Intel Macs will ever get, and next-LTS JDK 29 won't exist for them even as a build flag. If your migration plan involves the words "we'll deal with it at the next LTS," you now know exactly which one that is.