Choosing the JVM that powers your Vaadin application

Vaadin Flow is a full-stack Java web framework that runs all UI logic server-side on the JVM — eliminating the need for REST APIs or duplicate JavaScript. This lets teams deliver full-stack features in minutes or hours instead of days, speeding up development for internal tools, enterprise dashboards, and modern business apps.

Because Vaadin relies on the JVM to handle server-side UI logic, manage user sessions, and render events in real time, your choice of JVM isn’t just a runtime detail – it directly affects memory use, responsiveness, and scalability. 

Generally speaking all the leading JVM vendors provide good solutions for running modern business-grade Vaadin applications. In this post, we’ll make comparisons and focus on practical concerns like memory pressure, CPU usage, garbage collection pauses, and startup performance—especially in containerized and cloud environments where every millisecond and megabyte counts.

What it takes to run a Vaadin app at scale

Keeping the UI state in JVM memory for each user session can mean hundreds of KB per user on top of a ~200 MB baseline for the app. In today's world this is not a lot and servers can easily handle it, but it makes garbage collection efficiency and memory footprint critical for scalability and smooth UI updates. This is what we are talking about:

Likewise, in cloud deployments (e.g. containers/Kubernetes), CPU usage and startup/warm-up times impact how quickly new instances can handle load changes. 

Choosing the right JVM vendor for your Vaadin app

While all modern JVMs are based on OpenJDK, not all are created equal—especially when it comes to running demanding server-side Vaadin applications. From faster warm-ups to smarter garbage collection, each vendor brings something unique to the table. Some focus on low memory usage, others on low latency or long-term support, and a few offer commercial features for mission-critical deployments.

Below we summarize how major Java runtimes compare on these points for business Vaadin applications:

• Eclipse Adoptium (Temurin): The default community OpenJDK build, Temurin uses the standard HotSpot VM (G1 GC by default) and delivers baseline performance and memory management equivalent to Oracle’s reference JDK. It has no proprietary optimizations for GC or startup, but its broad industry backing and TCK-certification ensure reliability; it’s essentially a safe, well-tested choice with predictable behavior for Vaadin servers.
  
  
• Alibaba Dragonwell: Dragonwell adds unique enhancements targeting large-scale services. Its G1ElasticHeap can return unused heap memory to the OS, trimming the JVM’s memory footprint, and its JWarmup feature pre-compiles hot code based on prior profiling to reduce warm-up time and avoid CPU spikes during just-in-time compilation. These optimizations can benefit Java apps by reducing garbage buildup and latency as user count grows, though Dragonwell is primarily Linux (x86_64) only.
  
  
• Amazon Corretto: Corretto is Amazon’s OpenJDK distribution, hardened by running at AWS scale. It includes patches (contributed back upstream) aimed at improving performance and stability under heavy workloads. For example, Amazon has tuned garbage collection scheduling and memory management to prevent out-of-memory errors in large services. In practice, Corretto behaves like vanilla OpenJDK in memory footprint and startup, but with Amazon’s extra bug fixes and optimizations, it handles high load scenarios gracefully; the tradeoff is that official support is focused on AWS environments.
  
  
• Azul (Zulu & Platform Prime): Azul’s Zulu builds are TCK-tested OpenJDK binaries similar in performance to other standard distributions. The standout is Azul Platform Prime (Azul Zing), a specialized JVM designed for maximum throughput and consistent low latency under stress. The platform uses the C4 pauseless GC to virtually eliminate stop-the-world pauses, which means even data-intensive Vaadin apps won’t suffer noticeable GC hiccups. It also features ReadyNow! technology to accelerate warm-up (using profile data to JIT-compile code eagerly) and a Falcon JIT with an option to offload compilation threads, keeping CPU utilization smooth during peak loads. Azul Prime is a commercial product (with higher memory overhead for its GC) — it excels in demanding, latency-sensitive deployments, whereas Azul’s free Zulu offering covers more routine needs.
  
  
• BellSoft Liberica JDK: Liberica is known for its small footprint and cloud-ready packaging. It provides one of the smallest base images among JDKs (thanks to a slimmed-down JRE), which helps reduce container memory usage and startup disk overhead . In runtime behavior it’s equivalent to other OpenJDK-based JVMs (using G1 GC, etc.), but BellSoft also offers an optional build with CRaC (Coordinated Restore at Checkpoint) support. CRaC can snapshot a running Java instance and restore it in milliseconds, drastically improving startup times – BellSoft demonstrated up to 164× faster startup with CRaC in a Spring app. This is a big advantage for Vaadin applications that need to scale up quickly.
  
  
• Red Hat Build of OpenJDK: Red Hat’s distribution closely tracks OpenJDK but distinguishes itself by including the Shenandoah GC – a low-pause garbage collector ideal for large heaps . For Vaadin applications maintaining extensive in-memory UI state, Shenandoah can greatly reduce GC pause times (improving responsiveness) by doing most GC work concurrently. This comes with a slight throughput cost and higher CPU usage during collection, but it keeps latency consistent. Red Hat’s JDK is production-hardened (Red Hat runs it for its middleware), yet a practical consideration is that official binaries/support are limited to RHEL and Windows platforms. In summary, it’s a strong choice for minimizing GC pauses in large-scale Vaadin apps when your deployment aligns with Red Hat’s platform support.
  
  
• Oracle (Oracle JDK/OpenJDK): Oracle’s JDK is the baseline for performance — it uses the highly optimized HotSpot engine and G1 garbage collector by default, offering robust throughput and mature tuning for typical enterprise loads. It also includes Oracle’s ZGC (Z Garbage Collector) for those who need very low latency with huge heaps. In a Vaadin context, Oracle JDK will perform on par with the community builds for memory and CPU usage. Oracle JDK is well-tested and reliable; just ensure that the lack of certain niche features isn’t a bottleneck for your Vaadin deployment’s needs.
  
  
• SAP SapMachine: SapMachine is SAP’s downstream OpenJDK tailored for its enterprise cloud platform (SAP BTP). It inherits standard HotSpot behavior and GC algorithms from OpenJDK, so memory and CPU characteristics are similar to other distributions. The real focus is on stability and diagnostic enhancements for large, long-running business applications. SapMachine is proven in SAP’s own high-user-count services, and SAP sometimes includes patches for issues encountered in their products (with many fixes contributed upstream) . For a Vaadin app, it means you get a reliable, up-to-date JVM that handles heavy loads well. It doesn’t offer builds for older Java versions like 8 (only 17 up) , but is a solid choice if you value SAP’s testing pedigree.

With multiple vendors now offering OpenJDK builds—each with subtle differences in garbage collection behavior, warm-up time, and resource efficiency—picking the right JVM for a Vaadin workload can meaningfully impact both developer experience and production cost.

Comparison of major JVM vendors

JVM features that matter in business applications

Beyond performance, business application teams care deeply about licensing clarity, security patching, and long-term support. The table below compares the major JVM vendors from an operational perspective and highlights which ones offer commercial backing, predictable update policies, and strong ecosystem fit for serious production use.

The right JVM + Vaadin = faster delivery

Server-side Java remains one of the most robust and productive ways to build modern web applications—especially when using Vaadin. By keeping UI logic, state, and rendering all on the JVM, Vaadin eliminates the complexity of full-stack JavaScript and lets teams focus on delivering business value fast.

No matter which JVM you choose, the strength of Vaadin lies in its ability to build rich, reactive UIs without sacrificing the power, safety, and scalability of the Java ecosystem. Server-side Java lets you keep logic, state, and security under full control while benefiting from decades of performance tuning, modern tooling, and predictable behavior across JVM vendors.

Choosing the right JVM sharpens that advantage. It helps your Vaadin apps start faster, run leaner, and scale smoother, whether you’re deploying to bare metal, containers, or the cloud. And with the right combination, you get what every team wants: fewer surprises in production, happier users, and more time to focus on building real business value.

Further reading for JVM tuning:

• Speed Up Deployments with the Right JVM Features (JavaPro.io)
• What Is CRaC? Cut Java Startup from Minutes to Milliseconds (BellSoft)
• Running Vaadin Apps Natively or with Native Compilation (Vaadin Docs)
• 5 Tips to Optimize Memory Usage in Vaadin Applications (Vaadin Blog)