Two LTS releases now coexist. Virtual thread pinning is fixed. Memory is down 22%. Startup is faster. The gap is real — and it keeps growing.
Why Two LTS Releases Now Overlap
For years, Java teams had a simple rule: wait for an LTS release, upgrade, and stay there for as long as possible. That rule made sense when LTS releases came every three years. Today, however, Oracle has tightened the cadence — you now get a new LTS release every two years.
The result is a situation that most teams have not fully internalized yet: Java 21 (September 2023) and Java 25 (September 2025) are both LTS releases running in parallel. Java 21 free updates from Oracle run out in September 2026. Java 25, meanwhile, extends support all the way to 2033. That is a meaningful runway difference, and the clock is already ticking for teams that have not started planning.
What makes this particular upgrade cycle interesting — and, frankly, more urgent than most teams realize — is that Java 25 is not just a maintenance release with minor polish. It closes real technical gaps that were left open in Java 21, fixes a critical virtual thread limitation, and delivers measurable production performance gains across startup time, memory, and GC behavior. For teams building cloud-native or microservices workloads, those improvements translate directly to lower infrastructure bills.
Key dates to know
Java 21 LTS free Oracle updates expire September 2026. Java 25 LTS is supported until 2033. Between the two, approximately 66 JEPs (JDK Enhancement Proposals) were delivered across Java 22, 23, 24, and 25. Java 24 alone introduced 24 JEPs — a record for a single release.
So the question is no longer whether to move to Java 25 eventually. It is more a matter of when and how to do it without breaking anything. That is exactly what this guide addresses.
What Actually Changed Between Java 21 and 25
Before getting into benchmarks and migration checklists, it helps to understand what each version actually represents as a philosophy. Java 21 was widely described as the “modernization LTS” — the release that finally brought virtual threads, pattern matching for switch expressions, record patterns, and sequenced collections to a stable, production-ready state. It was ambitious and it changed how many teams write concurrent Java code.
Java 25, by contrast, is the “runtime evolution LTS”. Rather than introducing disruptive new concepts, it finishes the job that Java 21 started: features that were in preview get finalized, virtual threads get critical fixes, memory usage drops, and startup performance improves significantly. Additionally, it pulls in early groundwork from Project Valhalla for value types. In short, it is a release that makes everything you were already doing faster and more reliable.
Virtual Threads: A Critical Bug Gets Fixed
This is probably the single most important change for teams already using virtual threads. In Java 21, virtual threads could become “pinned” to a platform thread when they entered a synchronized block or called certain blocking native methods. This pinning behavior essentially defeated the entire purpose of virtual threads for any code — including third-party libraries — that used traditional locking. Java 25 includes JEP 491, which resolves virtual thread pinning so that synchronized methods no longer block the carrier thread. This is a massive unblocking for teams that hit this wall in production.
Compact Object Headers: Memory Shrinks by Up to 20%
Through JEP 519, Java 25 compresses object headers from 96 bits down to 64 bits on 64-bit architectures. In plain terms, every object on your heap shrinks by 4 bytes. That might not sound dramatic in isolation, but across millions of live objects in a typical Java service, it adds up quickly. The result is better cache locality, less GC pressure, and measurably smaller resident set sizes. Early real-world reports indicate memory savings in the 15–22% range for object-heavy applications.
AOT Cache and Project Leyden: Startup Gets Faster
One of Java’s longest-standing pain points in cloud-native environments has been slow startup and warmup time. Java 25 addresses this head-on via JEP 515 (Profile-Guided Optimization in the AOT Cache) and JEP 514 (AOT Command-Line Ergonomics). The JVM can now perform a “training run” that records which code paths are hot, then use that profile on subsequent startups to skip the warmup phase entirely. Benchmark results from the OpenJDK team show applications starting 15–25% faster compared to JDK 24 with a trained cache, with some enterprise configurations reaching much higher gains.
Scoped Values Finalize
Scoped values — a cleaner, safer alternative to ThreadLocal — were in preview in Java 21. In Java 25, they become a finalized API via JEP 487. Because scoped values are immutable and do not create per-thread copies, they scale much better with virtual threads. If you are building high-concurrency services, this is worth paying attention to.
Flexible Constructor Bodies and Compact Source Files
Two quality-of-life improvements round out the language changes. First, constructors can now include code before super(), removing an old restriction that sometimes forced awkward workarounds when you needed to validate parameters before calling the parent constructor. Second, compact source files mean small programs no longer need full class declarations with a static main method — a welcome simplification that makes Java feel less ceremonious for quick scripts and demos.
The Performance Numbers
Talk is cheap, so let us look at the actual data. The numbers below come from OpenJDK’s official performance blog (inside.java), production reports from enterprise adopters, and published benchmarks comparing identical workloads on both JVM versions.
Java 25 performance improvements over Java 21
The startup improvement stands out most for teams running containerized or serverless workloads, where cold-start time directly affects user experience and auto-scaling behavior. The memory reduction, meanwhile, is essentially free — you enable compact headers with a single JVM flag and the heap simply gets smaller. Fewer bytes on the heap means fewer GC cycles, which in turn improves latency consistency.
LTS support timeline comparison
The compact object headers feature is disabled by default in Java 25 and requires
-XX:+UseCompactObjectHeadersto activate. It is also incompatible with legacy stack locking (-XX:LockingMode=1). Do not enable it blindly — test with your specific workload first, since certain JNI-heavy applications may not benefit equally.
Feature-by-Feature Comparison Table
The table below maps the major features across both releases. “Final” means the feature is stable and recommended for production use. “Preview” means it is available but the API may still change in a future release — use it with care in long-lived production code.
| Feature | Java 21 | Java 25 | Impact |
|---|---|---|---|
| Virtual Threads | Final | Final + pinning fixed | High — critical for high-concurrency services |
| Pattern Matching for Switch | Final | Final + primitives | Medium — cleaner, more expressive code |
| Record Patterns | Final | Final | Medium — reduces boilerplate significantly |
| Scoped Values | Preview | Final | High — safer thread-local alternative |
| Structured Concurrency | Preview | Preview (refined) | Medium — cleaner multi-task lifecycle management |
| Foreign Function & Memory API | Final | Final + 2× alloc speed | High for native interop workloads |
| Compact Object Headers (JEP 519) | — | Final (opt-in) | High — up to 20% memory reduction |
| AOT Profile Cache (Leyden) | — | Final | High — 15–25%+ faster startup |
| Flexible Constructor Bodies | — | Final | Low-Medium — code ergonomics |
| Compact Source Files / Instance Main | — | Final | Low — reduces ceremony in small programs |
| ML-KEM (Quantum-Resistant Crypto) | — | Final | High for security-sensitive workloads |
| Generational Shenandoah GC | — | Final | Medium — better for large, long-running heaps |
| JFR CPU-Time Profiling | Execution-time only | CPU-time profiling | Medium — deeper production observability |
| ZGC Mapped Cache | — | Final | Medium — reduced heap fragmentation & RSS inflation |
| LTS Support (Oracle free updates) | Until Sept 2031 | Until 2033 | Strategic — 2 extra years of runway |
The Migration Decision Framework
Teams tend to avoid this conversation because “it’s complicated.” And honestly, some of that hesitation is reasonable — migration decisions depend heavily on your team’s specific constraints, your framework ecosystem, and your risk tolerance. Nevertheless, a few clear principles make the decision much simpler than it initially appears.
The first principle is straightforward: for new projects starting today, use Java 25. There is simply no good reason to start a new service on Java 21 in 2026. The tooling is mature, major frameworks like Spring Boot, Quarkus, and Micronaut already support it, and you get a longer support runway immediately.
The second principle is about timing for existing projects. Most framework ecosystems take roughly 6–12 months after an LTS release to fully mature their support for that release. Java 25 launched in September 2025, which means — right now, in early 2026 — the ecosystem is at a solid level of maturity for most common stacks. If you are on Spring Boot 3.4+ or Quarkus 3.x, compatibility is generally not an obstacle anymore.
Stay on Java 21 vs. Migrate to Java 25
Stay on Java 21 — for now
- You depend on a legacy framework not yet certified for Java 25
- Your compliance environment restricts rapid version changes
- You use JNI-heavy native code needing thorough testing with compact headers
- Your team is mid-cycle on a critical feature delivery
- You are on a non-Linux fleet and rely on JFR CPU attribution (Linux-only in Java 25)
Move to Java 25 — now
- You are starting a new project or service
- You use virtual threads and have hit pinning issues
- You operate in cloud-native, containerized, or serverless environments
- Memory and startup costs are a real concern for your infrastructure spend
- You want the full 2033 support runway for long-lived services
- Your framework stack is Spring Boot 3.4+ or Quarkus 3.x
One important nuance: the migration from Java 21 to Java 25 is genuinely low-risk compared to, say, upgrading from Java 8 to Java 11. Backward compatibility is strong. The JDK team at Oracle specifically designed Java 25 so that existing Java 21 codebases can migrate without code changes in most cases. The JEP removals are minimal, and none of them target features that modern Java applications typically use.
Good to know
Oracle’s No-Fee Terms and Conditions (NFTC) license allows free commercial use of Java 25 until one year after the next LTS release. That means you have real runway before any commercial licensing pressure kicks in.
A Practical Upgrade Checklist
If you have decided to move forward, the process is more straightforward than most teams expect. The steps below reflect what enterprise teams have successfully used in production migrations over the past few months.
First, check your build tooling. You will need Gradle 9.1+ or Maven compiler plugin 3.14.1+ for Java 25 compatibility. If you are behind those versions, start there — it is typically a one-line version bump.
Second, run a deprecation scan. This is the fastest way to surface anything that might break:
Check for deprecation warnings
javac -Xlint:deprecation -source 21 -target 21 src/main/java/**/*.java
Third, update your Docker base images. If you use Oracle, Eclipse Temurin, or Amazon Corretto images, the Java 25 variants are widely available:
Switch your Docker base image
# Eclipse Temurin (recommended for most teams) FROM eclipse-temurin:25-jdk-alpine # Amazon Corretto FROM amazoncorretto:25-alpine
Fourth, test compact object headers on your staging environment. This flag gives you the memory benefit with a single line but should be validated against your workload first:
Enable compact object headers (opt-in, test before production)
java -XX:+UseCompactObjectHeaders -jar your-app.jar
Fifth, if startup time matters to you, set up an AOT training run. This is especially impactful for services that scale in and out frequently:
Create and use an AOT cache (JEP 515)
# Step 1: Training run — captures hot code paths java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -jar your-app.jar # Step 2: Use the trained cache at startup java -XX:AOTMode=on -XX:AOTConfiguration=app.aotconf -jar your-app.jar
Sixth, if you are using virtual threads heavily, check for residual pinning scenarios after migration using Java Flight Recorder. The JEP 491 fix handles synchronized blocks, but there may still be cases with native frames worth auditing:
Detect virtual thread pinning with JFR
java -XX:StartFlightRecording=filename=app.jfr,settings=default -jar your-app.jar jfr print --events jdk.VirtualThreadPinned app.jfr
Pro tip
Always run your upgrade on a canary tier first, with the same load shape you expect in production. Measure startup time, memory RSS, and GC cycle frequency both before and after. Keep a rollback flag ready — particularly for the AOT cache and compact headers. One team learned this the hard way when their AOT cache was trained only on “happy path” flows and slowed down error-handling code paths significantly. Fix: include failure scenarios and chaos testing in your training run.
What We Have Learned
Java 21 was a genuinely strong LTS release that modernized the platform with virtual threads, pattern matching, and records. It earned its reputation as the stable, reliable choice. However, two years and 66 JEPs later, Java 25 closes the gaps that Java 21 left open — particularly the virtual thread pinning bug, which was a real blocker for teams with synchronized code in their stack.
Beyond bug fixes, the performance story is compelling in a way that directly affects infrastructure costs: 15–25% faster startup with AOT caching, up to 20% memory reduction with compact object headers, and a GC that handles large heaps with fewer pauses. These are not theoretical benchmark wins — they show up on cloud bills and in latency dashboards.
The migration decision is not really about whether to move — it is about when. For new projects, the answer is immediate. For existing Java 21 services, the right window is now, as the framework ecosystem has had time to mature. The backward compatibility risk is low, the tooling is ready, and the free Oracle support runway on Java 21 ends in September 2026. Waiting much longer simply limits your options without adding any real safety margin.
