Backend

JDK 27 Drops Intel Mac Support: The 13-Month Migration Window Starts Now

By Java编程爱好者 · Jul 9, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Any Java shop still running developer machines or CI runners on Intel Macs faces a hard stop in September 2027: no official JDK 27, and JDK 26 goes unpatched a year later. The migration isn't just about buying new hardware—teams need to revalidate native libraries, JNI dependencies, and container build pipelines against ARM64 before the deadline.

Summary

The OpenJDK project will remove the x86-64 macOS port beginning with JDK 27, scheduled for general availability in September 2027. Intel Mac users running the official JDK will be unable to upgrade past JDK 26, which itself reaches end-of-life in 2028 with no further security patches. The change is driven by Apple's progressive removal of Intel driver support from macOS and the disproportionate maintenance burden of sustaining an x86-64 port on a platform that has fully transitioned to Apple Silicon.

Performance data from JDK 26 benchmarks shows Apple Silicon (M3 Pro) completing sort workloads 33–44% faster than a 2020 Intel i9 Mac, with additional gains from G1 GC optimizations that exploit ARM's weak memory model. The JVM's platform-dependent nature means no amount of bytecode portability can paper over the missing native port.

Developers who cannot immediately replace hardware have two practical bridges: GraalVM Native Image compiles Java to standalone binaries that run without a JVM, and Docker multi-architecture builds (`docker buildx`) allow Intel Macs to produce ARM64 containers with only 5–8% performance overhead. Both approaches let teams decouple their build environment from the deployment target during the transition.

Takeaways

— JDK 27 removes the x86-64 macOS port entirely; Intel Macs will not be able to run the official JDK 27 build.

— JDK 26 enters end-of-life in 2028, leaving Intel Mac users without security patches if they stay on the last supported version.

— Apple has been stripping Intel driver support from macOS, making JVM maintenance on x86-64 macOS increasingly unsustainable.

— Apple Silicon (M3 Pro) delivers 33–44% faster sort performance than a 2020 Intel i9 Mac under JDK 26, with additional gains from G1 GC on ARM.

— GraalVM Native Image compiles Java to standalone binaries that bypass the JVM entirely, allowing Intel Macs to produce executables for other platforms.

— Docker's `buildx` multi-architecture builds let Intel Macs create ARM64 container images with only 5–8% performance overhead versus native builds.

— JNI-dependent libraries (OpenCV, TensorFlow) that lack ARM-native builds will fail on Intel Macs when targeting ARM; GraalVM or Docker containers are the workaround.

— macOS 15 Sequoia removed the last Intel drivers, causing JDK 26 to crash on startup; the fix shipped in JDK 26.0.2.

Conclusions

The removal of Intel Mac support is less a Java decision and more a downstream consequence of Apple's own deprecation of Intel drivers in macOS—the JVM team was effectively maintaining against a moving target with no upstream support.

G1 GC's performance advantage on ARM is not marginal; the weak memory model halves concurrent-marking pause times, which means the platform shift carries a real throughput improvement, not just a compatibility mandate.

GraalVM Native Image is positioned here as a migration tool rather than a performance optimization, which is an underappreciated use case: it decouples the build host architecture from the runtime target.

The class-file version lockstep (JDK 27 produces version 67, which JDK 26 cannot load) creates a hard compatibility boundary that will break mixed-version CI pipelines if not caught early.

Concepts & terms

G1 GC on ARM

The G1 garbage collector benefits from ARM's weak memory model, which reduces the synchronization overhead during concurrent marking. This can cut garbage-collection pause times roughly in half compared to x86, making ARM a particularly strong target for latency-sensitive Java workloads.

GraalVM Native Image

An ahead-of-time compilation tool that turns Java bytecode into a standalone native executable. The resulting binary does not require a JVM to run, which means it can be compiled on one architecture (e.g., Intel Mac) and executed on another (e.g., ARM64 Linux) without platform-specific JDK support.

Docker buildx multi-architecture builds

A Docker CLI plugin that extends `docker build` to produce images for multiple CPU architectures (e.g., amd64 and arm64) from a single build command. It allows an Intel Mac to create ARM64 containers by using QEMU-based emulation or native ARM nodes, with typical performance overhead of 5–8%.

JNI (Java Native Interface)

A framework that allows Java code to call and be called by native applications and libraries written in languages like C or C++. JNI libraries are compiled for a specific CPU architecture, so an ARM-native library cannot be loaded by a JVM running on x86-64, and vice versa.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗