With the recent release of Java 25, we took our usual look at its performance when running the Timefold Solver. Read on to see how the solver performs on Java 25, compared to previous Java versions.
Java 25 is the latest feature release of the Java platform, the language Timefold Solver is built on. It includes a fresh set of enhancements, previews, incubating features, and the usual reliability improvements. Read the full overview of included Java Enhancement Proposals (JEPs) here: https://openjdk.org/projects/jdk/25/
Java 25 became generally available in September 2025, and you can install it easily through SDKMAN, which is also how we like to manage our JDKs.
Along the way, we’ve created a powerful suite of benchmarking tools to easily compare Timefold Solver versions, configurations, and Java releases. In the rest of this post, we’ll share some of our insights with you when it comes to the performance of Java 25 with Timefold Solver.
We’ll start with score director micro-benchmarks, which we use regularly to establish the impact of various changes on the performance of Constraint Streams. These benchmarks do not run the entire solver; rather, they focus exclusively on the score calculation part of the solver.
They are implemented using Java Microbenchmark Harness (JMH), and they run in many Java Virtual Machine (JVM) forks and with sufficient warmup. This gives us a good level of confidence in the results. In fact, the margin of error on these numbers is only ± 2%.
As with our previous benchmarks, we configured the JVM with ParallelGC as the garbage collector (GC), instead of the default G1GC. ParallelGC has been the best GC for the solver in the past, as Timefold Solver is all about throughput and not latency.
Here is the Constraint Streams performance on Java 25 vs Java 21:
In all cases but 2, the difference between JDK 25 and 21 is within the margin of error (+/- 2%) for the benchmark. What that means is that we have observed no statistically significant change in performance between the two releases with these micro-benchmarks except for 2 cases, Nurse Rostering and Travel Tournament, where Java 25 performed around 4 percent better on these benchmarks.
We couldn’t really identify exactly why it’s better yet, but we aren’t too worried when the benchmarks return a “significantly better” result.
In addition to the micro-benchmarks above, we also run larger scoped applications, where we put the entire solver to work. For our benchmark, we use the median move calculation speed as our key metric.
Move calculation speed is the engine RPM of the solver. The higher it is, the faster the solver can try alternatives and converge toward a better solution. This makes it a good candidate for comparative benchmarking.
We ran the solver across 30 JVM forks. We selected a single benchmark which is a bit closer to a real application and ran it across a couple of Java versions. Once again, we used ParallelGC as the garbage collector of choice.
Here are the results:
While we haven’t established strict confidence intervals, run-to-run variance was small enough to have confidence in the observed improvements.
In this benchmark, Java 25 is almost 8% faster when compared to Java 21!
All benchmarks with these different Java versions used the same JAR file. These results clearly show that by using a newer version of Java, you not only get new features, but also increased performance. This is just one of the reasons why we love updating our pre-built models on app.timefold.ai to a newer Java version.
Successful scheduling optimization is built before the algorithm even starts. With cooking as a clear, practical metaphor, this article shows how preparation, integration, and feedback shape real-world results.
Blog
How to win in Field Service: Inside Timefold’s Field Service Routing API
The scheduling engine behind high-performance field service management platforms
Blog
Why every optimized plan needs an asterisk*
We talk a lot about “optimized” schedules, routes and plans, but optimized for what, exactly? In the real world, every plan is a trade-off between revenue, employee happiness, sustainability, and a dozen other priorities.