How to Improve the Performance of Legacy Java Code

Transcript:

Your application is running on Java 8 or 11. Well, the code is set and true, but the performance requirements are new. Do I speak in rhymes now? Well, anyway, you have to increase the performance, but there is a catch - you are not allowed to upgrade to a newer Java version, or the migration is planned for sometime in the future. But you have to reach KPIs now. So what do you do? Stick around as I show you the techniques that will help to speed up your Java application, reduce garbage collection pauses and memory footprint - all of that without upgrading the Java version.

Why legacy Java code underperforms? According to the survey our team recently conducted, half of the respondents are concerned about the performance of their legacy Java code. Almost a quarter allocate an additional budget to meet the new performance requirements, and yet migration to a newer Java version is not a business priority for 21 percent of the respondents. So the problem is that the management doesn't want to allocate resources or a budget to upgrade to a newer Java version - it is a lengthy, complicated process after all. But SLAs have to be met, and they are broken.

But why can't we let sleeping dogs lie? Why can't we leave the application alone, stay in legacy software, and be satisfied with the performance as it is now? After all, it has always been like that. What changed?

Well, many modern applications are deployed to the cloud, and the performance requirements in the cloud are different. Plus, as the user base grows, it leads to unpredictable traffic surges and growth - and the application can't handle the incoming traffic.

Why legacy Java struggles with modern workloads? First, the application takes long GC pauses and can't manage the incoming traffic due to older Java garbage collectors - and so, user dissatisfaction grows. Secondly, older Java versions have bigger CPU overhead, which leads to resource underutilization and increased costs. Thirdly, the memory footprint of legacy Java versions is bigger. As a result, you have to allocate more resources to cloud instances, which leads to increased cloud bills.

So what can we do about that?

Optimization strategies. There are three possible approaches to increasing the performance of Java workloads without upgrading the Java version: You can refactor the application code and adjust JVM configuration. You can scale the cloud infrastructure. You can use a fused JDK. Let's look at all three approaches.

Changes to the application code and JVM configuration. Tune the garbage collector. Garbage collection implementation can affect the application performance. There are several collectors to choose from, plus you can adjust the settings of each of them to reach the required result. GC tuning should be based on the workload. Parallel GC is best for CPU-bound batch processing. For Java 8, you can use CMS GC to decrease inner latency, as it is best suited for lower latency applications. You can also try G1 GC, which became the default collector in newer Java versions. For Java 11, try out G1 GC, as CMS GC is deprecated. You can also experiment with ZGC, which is a low-latency garbage collector, but keep in mind that it is not ready for production in this version. You can analyze GC behavior using Java profilers such as Java Flight Recorder.

Adjust JVM memory settings. You can reduce the memory footprint of your application by adjusting the JVM memory settings. In some cases, setting the minimum and maximum Java heap size is enough to reduce the Java memory footprint. To limit the total RAM consumption, you can use the Max RAM flags - they are very useful for containers. Of course, there are many more memory flags. I have collected the most common of them with the explanation in a dedicated article. The link is in the description.

Improve threading and concurrency. Optimizing concurrency can help the application to handle increased workloads and user interaction in a more efficient way. Some recommendations are to identify synchronization bottlenecks, use thread pools instead of raw threads, and monitor the concurrent code with jstack, Java Flight Recorder, or async profiler.

Optimize database calls. Inefficient database queries can hugely impact the application performance or even lead to memory leaks. First of all, you should analyze the queries using a specialized tool for that or a profiler that supports SQL assessment. For instance, you can use Digma AI in IntelliJ IDEA Ultimate. You can also use EXPLAIN ANALYZE profiling tools if you use MySQL. Some general recommendations: use the JPA second-level cache before considering external caches like Redis, avoid N+1 query problems, and batch fetch related entities properly instead of using lazy loading.

Performance optimizations with the right cloud infrastructure. Changing the code is problematic and complicated, so another approach to boosting the performance of the application is to scale the cloud infrastructure. There are two approaches to scaling: vertical scaling and horizontal scaling.

Vertical scaling (or scaling up) is about adding more CPU, memory, or disk to a single machine - so, improving the hardware. Its benefits are simple setup, no code changes are required, and it can improve the single instance performance quickly. But it can be expensive for large-scale needs, and it doesn't improve availability of the application.

Horizontal scaling (or scaling out) is about adding more instances to distribute the load. Horizontal scaling works well for stateless Java applications. It is cost-effective with auto-scaling in cloud environments, and it improves fault tolerance. But it might require code changes, such as configuring the session management.

Optimize memory usage in the cloud. Instead of fine-tuning the JVM memory options, you can change the base image for your containers and use lightweight Alpine Linux - this will immediately reduce the disk space consumed by the application. In Java 11, you can use jlink to cut out a custom runtime and reduce the container image size even more.

Switch to a fused JDK. Newer Java versions include lots of new features and JVM improvements which are worth the migration. But if you need a performance boost right now, and upgrading the Java version is currently not an option, you can use a fused JDK. It can increase the performance of your application without code changes.

So what is a fused JDK? I'm talking about Liberica JDK Performance Edition. It couples JDK 8 or 11 with JVM 17. As a result, it brings the improvements to garbage collection, intrinsics, and compiler to the older JDK versions. For instance, you get the improved G1 GC, production-ready ZGC, and Nano GC for your JDK 8 to 11-based workloads without upgrading the Java version. Essentially, your dependencies are preserved - you don't need to change the library versions or the application code. In some cases, you might need to change some JVM options which were deprecated or renamed in later JVM versions.

So you stay on JDK 8 or 11, and the performance of your application gets immediately improved by 10 or even 15 percent, even at the default settings. And of course, you can switch to a modern low-latency collector such as ZGC, and it will do wonders to latency. Liberica JDK is 100% open source. It means that you can easily migrate to or from it without vendor lock-in.

Conclusion. So what options do we have? You can change the application code, or you can scale the cloud infrastructure. But it will only help so much, because older JDK versions have performance limits that you can't surpass. Plus, you need to change a lot - and that costs time and money. So the easiest solution is to switch to Liberica JDK Performance Edition.

Don't take my word for it - you can read more about Liberica JDK Performance Edition under the link I pasted in the description box. You can also request a demo version of Liberica JDK Performance Edition to test it with your code and see which performance improvements you can get. Don't forget to like this video, subscribe, and watch other related videos on our channel - such as the overview of Java garbage collectors or profiling Java applications. See you next time.

Summary

In this video, we explore how to improve the performance of Java 8 or 11 applications without upgrading to a newer Java version. Many companies face modern performance demands, especially in the cloud, but migration is often delayed due to cost and complexity. The video presents three approaches: optimizing application code and JVM settings, scaling cloud infrastructure, or using a fused JDK like Liberica JDK Performance Edition. This fused JDK pairs legacy Java with a modern JVM, enabling better garbage collection, lower latency, and improved efficiency without changing application code. Additional tips include tuning GC, memory, threading, and database queries. With these strategies, performance can improve by up to 15% even on legacy Java.

Tags

JDK ProjectsFeatures & Tools
Videos
card image
Feb 6, 2026
Backend Developer Roadmap 2026: What You Need to Know

Backend complexity keeps growing, and frameworks can't keep up. In 2026, knowing React or Django isn't enough. You need fundamentals that hold up when systems break, traffic spikes, or your architecture gets rewritten for the third time.I've been building production systems for 15 years. This roadmap covers three areas that separate people who know frameworks from people who can actually architect backend systems: data, architecture, and infrastructure. This is about how to think, not what tools to install.

Watch Now
Videos
card image
Jan 29, 2026
JDBC Connection Pools in Microservices. Why They Break Down (and What to Do Instead)

In this livestream, Catherine is joined by Rogerio Robetti, the founder of Open J Proxy, to discuss why traditional JDBC connection pools break down when teams migrate to microservices, and what is a more efficient and reliable approach to organizing database access with microservice architecture.

Watch Now

Further watching

Videos
card image
Feb 27, 2026
Spring Developer Roadmap 2026: What You Need to Know

Spring Boot is powerful. But knowing the framework isn’t the same as understanding backend engineering. In this video, I walk through the roadmap I believe matters for a Spring developer in 2026. We start with data. That means real SQL — CTEs, window functions, normalization trade-offs — and understanding what ACID and BASE actually imply for system guarantees. Spring Data JPA is useful, but you still need to know what happens underneath. Then architecture: microservices vs modular monolith, serverless, CQRS, and when HTTP, gRPC, Kafka, or WebSockets make sense. Not as buzzwords — but as design choices with trade-offs. Security and infrastructure follow: OWASP Top 10, AuthN vs AuthZ, encryption in transit and at rest, Docker, Kubernetes, Infrastructure as Code, and observability with Micrometer, OpenTelemetry, and Grafana. This roadmap isn’t about mastering every tool. It’s about knowing what affects reliability in production.

Watch Now
Videos
card image
Feb 18, 2026
Build Typed AI Agents in Java with Embabel

Most Java AI demos stop at prompt loops. That doesn't scale in production. In this video, we integrate Embabel into an existing Spring Boot application and build a multi-step, goal-driven agent for incident triage. Instead of manually orchestrating prompt → tool → prompt cycles, we define typed actions and let the agent plan across deterministic and LLM-powered steps. We parse structured input with Ollama, query MongoDB deterministically, classify risk using explicit thresholds, rank affected implants, generate a constrained root cause hypothesis, and produce a bounded containment plan. LLM handles reasoning. Java enforces rules. This is about controlled AI workflows on the JVM — not prompt glue code.

Watch Now
Videos
card image
Feb 12, 2026
Spring Data MongoDB: From Repositories to Aggregations

Spring Data MongoDB breaks down fast once CRUD meets production—real queries, actual data volumes, analytics. What looks simple at first quickly turns into unreadable repository methods, overfetching, and slow queries. In this video, I walk through building a production-style Spring Boot application using Spring Data MongoDB — starting with basic setup and repositories, then moving into indexing, projections, custom queries, and aggregation pipelines. You'll see how MongoDB's document model changes data design compared to SQL, when embedding helps, and when it becomes a liability. We cover where repository method naming stops scaling, how to use @Query safely, when to switch to MongoTemplate, and how to reduce payload size with projections and DTOs. Finally, we implement real MongoDB aggregations to calculate analytics directly in the database and test everything against a real MongoDB instance using Testcontainers. This is not another MongoDB overview. It's a practical guide to actually using Spring Data MongoDB in production without fighting the database.

Watch Now