OpenJDK 27 arrives as a short-lived feature release
Before looking at any charts, it helps to know what kind of release OpenJDK 27 is. According to the OpenJDK project, JDK 27 reached General Availability on 15 September 2026, and production-ready binaries under the GPL are available from Oracle; binaries from other vendors will follow shortly. Oracle's release announcement says Java 27 includes nine enhancements that are significant enough to warrant their own JDK Enhancement Proposals (JEPs), including four preview features and one incubator feature.
Java 27 is not a long-term support release. Oracle says it will provide updates to JDK 27 until March 2027 when it will be superseded by Oracle JDK 28. The current LTS line is JDK 25, and Oracle's download page says JDK 25 will receive updates under the NFTC, until September 2028, a year after the release of the next LTS. The same page includes a deadline many shops will care about this month: JDK 21 will receive updates under the NFTC, until September 2026. After that, subsequent JDK 21 updates from Oracle move to the Java SE OTN licence.
The release's headline features are about security, not speed. DevOps.com reports that Java 27 introduces post-quantum hybrid key exchange for TLS 1.3 using ML-KEM, and that Oracle is moving toward monthly critical security patch updates alongside its existing quarterly cycle. Oracle's marketing also promises thousands of performance, stability, security, and productivity improvements. That claim is vague, so a benchmark run eight days after release is useful as a check against it.
How Phoronix tested JDK 8 through OpenJDK 27
Michael Larabel of Phoronix ran the tests on a System76 Thelio Major workstation with an AMD Ryzen Threadripper 9980X, running Fedora Workstation 44. He said he had not looked at OpenJDK performance in a few years, so after Java 27 shipped he retested every major OpenJDK release back to JDK 8, which dates from 2014.
For reproducibility, each release was tested out of the box, using the official OpenJDK binaries with their default configuration. No garbage-collector selection, heap sizing or JIT flags were changed. That choice has consequences. The results reflect what each JDK does on its own, including changes in default behaviour between releases, and do not show how each runtime performs after tuning. Anyone who runs production services with carefully set JVM flags is looking at a different situation from this test.
The workloads came from two established suites. DaCapo runs real open-source Java applications such as Eclipse, Apache Tomcat, Apache Lucene, H2 and Spring Boot. Renaissance focuses on concurrency and functional-style workloads, with tests built on Scala, Akka, Finagle and similar frameworks. Together they are closer to real application behaviour than microbenchmarks.
Older runtimes caused one important problem. OpenJDK 10 and older failed to run the DaCapo Eclipse and Apache Tomcat tests, and none of the Renaissance suite ran on those versions either. As a result, JDK 8, 9 and 10 appear in only part of the comparison. Any summary that says JDK 8 was compared against JDK 27 is really describing a subset of the workloads.
Where OpenJDK 27 won outright
Across the DaCapo tests, OpenJDK 27 finished first, or tied for first, in a long list of workloads:
- In the Batik SVG Toolkit test, performance improved slightly with almost every OpenJDK release, and OpenJDK 27 was fastest.
- The H2 Database Engine followed the same pattern, with small gains across roughly twelve years of releases and OpenJDK 27 on top.
- In the Apache Lucene Search Index test, OpenJDK 26 and 27 produced the best results.
- In the Apache Lucene search engine test, a severe regression from OpenJDK 19 through 21 was fixed in OpenJDK 22, and a further gain in OpenJDK 27 produced the best result of any release tested.
- The Avrora simulation framework ran best on OpenJDK 26 and 27.
- BioJava improved noticeably from OpenJDK 26 to 27, with 27 fastest.
- ZXing barcode image processing also ran best on OpenJDK 27.
The Renaissance suite showed a similar pattern. Phoronix reported OpenJDK 27 in first place for Finagle HTTP requests and for Jenetics, the Java genetic-algorithm library, which improved steadily from OpenJDK 11 onward. The Akka Unbalanced Cobwebbed Tree test was a tie between OpenJDK 21 and 27. For Savina Reactors.IO, a large gain arrived in OpenJDK 17, followed by small fluctuations, and OpenJDK 27 remained among the strongest results.
Most of these wins are small. Phoronix repeatedly describes the gains as slight or incremental. The long-term trend is clear, but the jump from OpenJDK 26 to 27 on its own is usually modest. BioJava and the Lucene search engine are the exceptions where 27 made a visible jump.
The workloads where JDK 8 and early releases still win
Other results complicate the "newer is always faster" reading. They are the most useful part of the dataset for anyone planning a migration.
GraphChi, a graph-processing workload, slowed in OpenJDK 16 and again in 17. OpenJDK 21 recovered some of the loss, and releases 26 and 27 improved further. Even so, the newest releases still trailed the earliest ones tested. In the FOP print-formatter test, results moved up and down across releases. OpenJDK 26 improved, 27 held that level, and both still fell short of JDK 8.
Spring Boot is the most revealing case, because so many enterprise Java services run on it. Phoronix found that OpenJDK 27 only matched the performance of the JDK 9 era. Several releases in between regressed, and recovery began around OpenJDK 20. Apache Tomcat followed a similar path: it regressed from OpenJDK 13 through 19 under default settings and has improved only slightly since. The research notes supplied with the Phoronix charts indicate that an OpenJDK 25 point release, not 27, was the fastest Tomcat result.
DaCapo Eclipse, which cannot run on JDK 10 or older, shows the more typical modern pattern. It improved substantially in OpenJDK 21, and later releases stayed ahead of earlier ones. OpenJDK 27 is described as only very slightly faster than the releases just before it.
For a web-service team on an older JDK, the conclusion is that upgrading is likely to be faster overall, but the typical Spring Boot or Tomcat application should not expect the largest gains. Because the tests used default settings, some of those mid-series regressions may come from changed defaults, such as garbage-collector or ergonomics choices, rather than slower code. The benchmark does not isolate individual changes, so this is our inference and not something Phoronix found.
The composite result and the OpenJDK 11-to-17 jump
Phoronix combined the results into geometric means. A geometric mean averages many benchmark ratios without letting one very large result dominate. In its conclusion, Phoronix reports that OpenJDK 27 had the best overall result among the workloads that ran all the way back to JDK 8.
JDK 8, 9 and 10 could not run many of the tests, so Phoronix also calculated a second geometric mean that excludes those three versions and covers the wider set of workloads. On that measure it reports a 13.6% improvement in out-of-the-box performance from OpenJDK 11 to OpenJDK 17. That figure applies to both LTS generations and to the two-LTS upgrade many organisations have already made. The article gives no single percentage for the full JDK 8-to-27 span.
Keep the testing conditions in mind when reading these numbers. They come from one high-core-count AMD workstation running Linux with default JVM settings. Phoronix published raw data for the run on OpenBenchmarking.org, which lets readers check individual chart values. No other outlet has run a comparable cross-version sweep of Java 27, so these results are one detailed dataset and should not be treated as the industry consensus.
Why a Linux benchmark still applies to Windows Java shops
None of these tests ran on Windows. The OpenJDK runtime, HotSpot JIT compiler and garbage collectors are largely shared across operating systems, so the relative trends are a reasonable guide for Windows developers and administrators. That is an inference. The absolute numbers, and any OS-specific behaviour in threading, file I/O or networking, cannot be carried over directly. A Tomcat or Spring Boot service on Windows Server may follow a similar regression-and-recovery pattern across JDK versions, but only your own testing on your own hardware can confirm it.
The processor also matters. The Threadripper 9980X has far more cores than a typical developer laptop or small VM. JVM defaults for garbage-collector threads, heap size and compiler threads scale with the hardware they detect, so a four-vCPU cloud instance could rank releases differently.
What this means for you
Stay on an LTS release unless you have a specific reason not to, and run your own benchmarks before trusting any general ranking for your workload. The Phoronix data supports moving off JDK 8 and 11. It does not support switching production systems to OpenJDK 27 for speed alone, given that 27 receives Oracle updates only until March 2027.
- Teams still on JDK 8 or 11 should treat these results as a reason to plan a move to JDK 25 LTS, since the combined results favour modern releases and Phoronix measured a 13.6% default-configuration gain from 11 to 17 alone.
- Spring Boot and Tomcat operators should expect smaller gains than other workloads, because Phoronix found both regressed across several mid-series releases before recovering.
- Workloads similar to GraphChi or FOP may still run faster on older runtimes, so test them against your current JDK before assuming an upgrade helps.
- Administrators relying on Oracle's no-fee JDK 21 builds should note that free NFTC updates for that line end in September 2026.
- OpenJDK 27 is a sensible target for development and testing, especially to try its post-quantum TLS 1.3 key exchange, but it will be replaced by JDK 28 within six months.
- Any comparison you run should keep JVM flags constant or deliberately set, because differences in default settings between releases can look like gains or losses in the runtime itself.
After more than a decade of releases, the Phoronix sweep shows the HotSpot runtime getting faster overall, with OpenJDK 27 leading most workloads on this machine. Some important server workloads took until the 20-series releases to recover lost ground. The practical upgrade target is JDK 25 LTS. JDK 28, due in March 2027 with Oracle already promoting early access builds that include Project Valhalla, is the next release likely to change these rankings.