JDK 27 reaches general availability in mid-September 2026 carrying nine JEPs. Four are previews on their third, fifth, seventh, or twelfth round. Rust 1.97.0, released 9 July 2026, has an entire language section of five bullet points, four of which are lints and target features.
Both languages spent the last year rebuilding their insides instead of their surfaces. That reframes every "what's new in" post published since January, including the optimistic ones.
What Java actually delivered
The real work has been in the runtime.
Compact object headers cut an object header from 96 bits to 64 on 64-bit machines. Experimental in JDK 24, a supported product feature in 25, and on by default in JDK 27. The JEP authors measured 22% less heap and 8% less CPU time on SPECjbb2015, with GC frequency down 15%. Amazon validated it across hundreds of production services, largely through backports to JDK 21 and 17, which carries more weight with me than any benchmark table.
G1 becomes the default collector in all environments in JDK 27, displacing Serial on small machines. JEP 522 in JDK 26 cut G1's x64 write barriers from roughly 50 instructions down to 12, worth 5–15% throughput on code that heavily modifies object references. It costs about 2 MB of native memory per gigabyte of heap, and the JEP states that plainly rather than hiding the trade.
Project Leyden is the change enterprise teams will feel first.
Those numbers come from Ralph Schaer's April 2026 measurements on a single Hetzner box, 15 runs per strategy, medians reported, with no JDK vendor involved. Leyden's AOT cache takes Spring Petclinic from 6.28 seconds to 2.70. Checkpoint/restore takes it to 1.01, which is the part nobody writes headlines about. One caveat the Quarkus team has been honest about: AOT caching buys startup time and does not meaningfully reduce memory footprint. If you need a small resident set, this is not the tool.
Virtual threads have been final since JDK 21 in September 2023. Structured concurrency, the API that makes virtual threads tolerable to write against, is on its seventh preview round in JDK 27.
Seven.
The Vector API is the sharper problem. Twelve incubator rounds since JDK 16, and it stays there until Project Valhalla lands, which means Java has no stable SIMD API in 2026. Valhalla finally has a date: JEP 401, Value Objects, is targeted at JDK 28 as a preview, alongside JEP 539 for the bytecode verification it needs. Null-restricted types, where most of the flattening payoff lives, were split into a separate draft with no release attached.
As an aside, my favourite small indignity in this release cycle: "Stable Values" was renamed "Lazy Constants" and is now on its third preview under a second name, while PEM Encodings has collected four JEP numbers (470, 524, 538, 542) for one feature. Java's process is careful. It is not fast, and the JEP numbers keep the receipts.
What Rust actually delivered
Rust 1.97.1 landed 16 July 2026. Six weeks after 1.96.0, six weeks after 1.95.0, and so on backwards through every release I checked. The train has not slipped once.
What arrived on it is modest. if let guards on match arms and cfg_select! in 1.95.0. The core::range types in 1.96.0. In 1.97.0, v0 symbol mangling became the default, filed under Compatibility Notes because it can break older debuggers and profilers.
The gaps matter more than the additions. Async fn in traits has been stable since 1.75.0 in December 2023, and still is not dyn-compatible, which is why async-trait remains in wide use two and a half years on; native async dynamic dispatch sits on the 2026 goal slate as a Medium item. gen blocks are nightly-only with an open soundness bug for coroutines that reborrow from themselves, and no target version. A stable ABI does not exist at all: crABI never made it past an experimental feature-gate proposal, so stabby and abi_stable fill the hole.
Planning restructured this year from six-month cycles to an annual one: 76 goals split 18 Large, 40 Medium, 18 Small, plus nine multi-year roadmaps with named owners. Polonius Alpha looks likeliest to ship, its enabling PR landed and described as stabilizable. The parallel compiler front-end is the opposite case, still behind -Zthreads seven years in with 4 ICE reports and 11 reproducibility issues open, and a June 2026 plan describing 9 to 12 months of work before stabilization is even proposed. Two 2025 goals went unfinished; the Cranelift backend's stated reason was lack of funding.
One correction while I'm here, because it keeps circulating: there is no Rust 2027 edition. I read compiler/rustc_span/src/edition.rs on master. It defines 2015, 2018, 2021, 2024, and a permanently-unstable EditionFuture placeholder. No call for proposals exists.
Compile times did improve. Nicholas Nethercote's July 2026 report puts mean wall-time reduction at 5.59% between 3 December 2025 and 29 July 2026, which drops to 2.90% once you exclude rustdoc, where a 37.92% improvement did most of the lifting. Cite both numbers or you're overselling it. Meanwhile the first Rust compiler performance survey, 3,700-plus responses, found roughly 45% of people who stopped using Rust named compile times as a factor, and 55% still wait more than ten seconds for an incremental rebuild. Better, and still the loudest complaint.
The performance comparison, honestly
Most Rust-versus-Java performance numbers in circulation are not usable, and I'd rather say that than repeat them.
The energy and runtime ranking everyone quotes, where Rust sits at 1.04x C and Java at 1.89x, traces to Pereira et al. A 2024 re-examination (arXiv:2410.05460) corrected RAPL measurement errors, re-ran 118 of 130 language-benchmark pairs, and concluded that language implementation choice "has no significant impact on energy consumption beyond execution time." TechEmpower's newest completed round is Round 23 from March 2025, and its own writeup attributes the headline gains "entirely" to new servers and fibre networking. The production figure that circulates hardest, a bank replacing 3 cores and 3.8 GB of Java with 0.25 cores and 8 MB of Rust for "486 times" the memory efficiency, drew a published rebuttal pointing out that 3.8 GB indicates a badly built service rather than JVM overhead, which typically runs 150–250 MB.
Two things are defensible. Cloudflare's Infire inference engine, written in Rust, hit 40.91 req/s at 25% CPU load against vLLM 0.10.0's 38.38 req/s at 140%: about 7% more throughput for roughly 5.6 times less CPU. Vendor-authored, one model, one hardware configuration. And Google's Android data, covering 2019 to 2025, reports 0.2 memory-safety vulnerabilities per million lines of Rust against a C/C++ historical baseline near 1,000, with Rust changes needing about 20% fewer revisions, 25% less review time, and roughly 4x fewer rollbacks.
Look at what that evidence is actually about. Rust's measured, replicated advantages are memory safety and per-process overhead. Not raw throughput against a warmed-up JVM.
Where each one sits in AI work
Neither language is taking model training from Python, and pretending otherwise wastes your time. What happened is a split by layer.
Rust went underneath Python. Hugging Face's tokenizers pulled 10.8 million downloads in 90 days, hf-hub reached 1.0.0 in July 2026, and uv sits at roughly 88,000 GitHub stars. Most people running Python AI code are running Rust and don't know it. Java went above it instead, into the layer where a model output has to reach a system of record. Spring AI 2.0 went GA on 12 June 2026 atop Spring Boot 4.x, and LangChain4j shipped six releases in the eight weeks to 15 August 2026. Deep Java Library, by contrast, has not shipped since 16 December 2025 and is still pre-1.0; treat that lane as closed.
Azul's 2026 survey (vendor-authored, 2,039 respondents, fielded September to November 2025) reports 62% of enterprises using Java for production AI functionality, up from 50% a year earlier. Take the number loosely and the direction seriously.
What I would start a new enterprise project on
Java 25 LTS, and I would want a specific reason before choosing anything else.
Premier support runs to September 2030 and extended to 2033. Startup is largely fixed. Compact headers cut memory. Spring AI and LangChain4j are where AI integration is actually maturing for business systems, and you can hire for all of it. I'd skip JDK 26 and 27 despite the compact-header default, because non-LTS premier support ends in six months and JDK 29 is the next LTS in September 2027.
Rust earns a new project on a shorter, checkable list: sustained per-request CPU or memory pressure that dominates your cloud bill, a hard latency ceiling that GC pauses break, a security boundary parsing untrusted input, or a component that must ship as a library with no runtime attached. Data and inference plumbing qualifies. A CRUD service with a Postgres behind it does not, and choosing Rust there buys you the compile times 45% of quitters cited in exchange for safety guarantees your integration tests were already providing.
The option I'd actively reject is the tempting middle path: starting a greenfield project split across both, Rust for the hot core and Java for the application. I've seen the appeal and the arithmetic rarely works, because you pay two toolchains, two hiring pipelines and an FFI boundary at exactly the moment you understand your performance profile least. Ship the Java version, measure it, then carve out the 3% that deserves Rust. The Foreign Function and Memory API has been final since JDK 22 specifically so that carve-out is cheap later.
One thing I can't resolve. JEP 401 previews value objects in JDK 28 around March 2027, and I don't know how much of Rust's memory-layout advantage that erases in practice, because no independent benchmark of a value-types JVM against equivalent Rust exists yet. Anyone who quotes you a figure for that today is guessing. It's also the single result I'd most want to see, since it decides whether the boundary I just drew holds through 2028 or moves.