Cut Jakarta EE Startup Times from Seconds to Milliseconds with CRaC 

Jakarta EE applications can take anywhere from several seconds to over a minute to start, depending on their size and complexity. In traditional deployments this might not matter much, but in modern cloud environments with autoscaling and containerized workloads, slow startup times can impact user experience and operational costs. 

Coordinated Restore at Checkpoint (CRaC) offers a different approach where, instead of optimizing startup, it largely eliminates it. Applications that normally take 10-15 seconds to start can be ready in under 100 milliseconds. 

This post explains what CRaC is, why it matters for Jakarta EE deployments, and whether it makes sense for your architecture. 

The Startup Time Problem 

Every time you deploy a Jakarta EE application, the JVM goes through the same expensive initialization process: 

• Load and verify thousands of classes 

• Discover and initialize CDI beans 

• Set up JPA entity managers and connection pools 

• Execute static initializers 

• Wait for the JIT compiler to warm up and optimize hot code paths 

For a typical REST API with JPA and CDI, this takes 10-20 seconds. Larger applications can exceed a minute. 

In traditional deployments where you start a few application servers and leave them running for days or weeks, startup time doesn’t matter much. But in modern cloud environments with autoscaling, blue-green deployments, and container orchestration, you’re starting instances constantly. Each startup delay compounds: 

• Autoscaling lags behind traffic spikes, causing request failures 

• Rolling deployments take longer, extending the window where you’re running mixed versions 

• Development feedback loops slow down when every code change requires a full restart 

• Serverless-style workloads become impractical for Jakarta EE applications 

• How CRaC Works – Save Once, Restore Many Times 

CRaC takes a fundamentally different approach. Instead of optimizing startup, it eliminates most of it. 

The concept behind it is quite simple.You start your application once, let it fully initialize and warm up, then take a snapshot of the entire JVM state. This snapshot includes everything – your initialized objects, compiled code, loaded classes, even the state of the JIT compiler’s optimizations. You save this snapshot to disk as a checkpoint image. 

When you need to start a new instance, instead of booting from scratch, you restore from the checkpoint. The JVM loads the snapshot and continues from exactly where you left off. No class loading, no bean discovery, no warmup period. The application is immediately ready to handle production traffic at full performance. 

Think of it like hibernating your laptop versus doing a cold boot. Hibernation saves the entire state of your system and restores it in seconds. Cold boot has to initialize everything from scratch and takes minutes. 

Real Performance Impact 

Numbers from a typical Jakarta EE REST API with JPA, CDI, and bean validation: 

Traditional startup: 

• 12.3 seconds until the application accepts requests 

• Additional 2-3 seconds until JIT compilation reaches steady-state performance 

• Total time to full performance: 14-15 seconds 

CRaC startup: 

• 87 milliseconds until the application accepts requests 

• Zero additional warmup – the JIT compiler’s work is already done 

• Total time to full performance: 87 milliseconds 

That’s 140x faster. 

The checkpoint image for this application is 380MB. Creating the checkpoint takes about 2 seconds. You only create the checkpoint once – typically during your build or deployment pipeline – then restore from it hundreds or thousands of times as you scale instances. 

What Makes CRaC Possible 

CRaC operates as a checkpoint/restore mechanism that captures the process state. This function is comparable to how container checkpoint technologies or virtual machine snapshots work; it is not a JVM optimization or tuning technique. 

The original CRaC implementation uses CRIU (Checkpoint Restore In Userspace), a Linux kernel feature. Azul Systems has also developed an alternative engine, called Warp, that is integrated directly into their JVM builds. Both achieve the same outcome through different technical approaches. 

The key innovation in CRaC is the API for managing resources. Before taking a checkpoint, the JVM notifies your application so it can properly close resources that can’t be checkpointed – database connections, open files, network sockets. After restore, the JVM notifies your application again so it can reopen these resources. 

This notification mechanism is what makes CRaC practical for enterprise applications. Without it, you’d restore your application with stale database connections and broken network sockets. 

What CRaC Doesn’t Do 

CRaC isn’t a universal solution. It works well for certain architectures and struggles with others. 

Works well for: 

• Stateless microservices that can scale horizontally 

• REST APIs without long-lived connections 

• Applications where state lives in external systems (databases, Redis, message queues) 

• Container-based deployments that restart frequently 

Struggles with: 

• Applications that maintain significant in-memory state 

• Long-lived WebSocket or streaming connections 

• Heavy reliance on third-party libraries that weren’t designed for checkpoint/restore 

• Non-Linux platforms (CRaC currently requires Linux) 

The fundamental constraint is that some resources can’t be frozen and restored. An open database connection to a server that your application connected to 10 minutes ago won’t work after restore – the database server has likely closed that connection. Your application needs to handle closing and reopening these resources. 

What Changes in Your Application 

CRaC requires changes to how you manage resources. The extent depends on what your application does. 

For a simple REST API that uses connection pooling and doesn’t maintain much state, the changes are minimal – mostly adding lifecycle hooks to properly close and reopen connection pools. 

For applications with scheduled tasks, message-driven beans, or complex state management, you’ll need more extensive changes to ensure these components properly handle checkpoint and restore events. 

Payara Micro Enterprise (version 6.33.0 in December 2025 release) handles some of this automatically – the server runtime knows how to checkpoint and restore its internal components. But application-specific resources like database pools, JMS connections, and HTTP clients require your code to participate in the checkpoint/restore lifecycle. 

When to Consider CRaC 

CRaC makes sense when startup time directly impacts your business or operational metrics. 

You’re paying for the problem: 

• Cloud costs increase because you overprovision to handle autoscaling lag 

• Support tickets spike during traffic surges because instances don’t scale fast enough 

• Deployment windows extend because rolling updates take too long 

You have the right architecture: 

• Microservices or containerized deployments that restart frequently 

• Stateless or mostly stateless applications 

• Linux-based infrastructure 

• Willingness to invest engineering time in resource lifecycle management 

You can measure the benefit: 

• You know your current startup times and can quantify the cost 

• You have metrics showing autoscaling lag or deployment delays 

• You can calculate ROI on the engineering effort 

• When to Skip CRaC 

Don’t invest in CRaC if: 

• Your applications restart infrequently (traditional monolithic deployments) 

• Startup time isn’t causing measurable problems 

• Your infrastructure is Windows or macOS based 

• Your application relies heavily on third-party libraries without CRaC support 

• You can’t dedicate engineering effort to implementing resource lifecycle management 

The engineering effort to properly implement CRaC isn’t trivial. You need to audit every resource in your application, implement lifecycle callbacks, and thoroughly test checkpoint and restore behavior. If startup time isn’t a significant pain point, that effort is better spent elsewhere. 

Getting Started 

If the tradeoffs make sense for your situation, start small: 

1. Pick a pilot service – Choose a simple, stateless microservice with clear startup time problems 

2. Measure baseline – Record current startup times and the business impact 

3. Evaluate the technical preview – Payara Micro Enterprise 6.33 includes CRaC as a technical preview 

4. Quantify the improvement – Measure actual performance gains in your environment 

5. Assess the effort – Document what code changes were required 

6. Calculate ROI – Compare the benefit against the engineering cost 

If the pilot succeeds, you can gradually expand CRaC to more services. If it doesn’t provide enough value, you’ve limited your investment to a single service. 

What’s Next 

This post covered the concepts and business considerations around CRaC. If you’re interested in the technical implementation, e.g. what code changes are required, how to handle database pools and scheduled tasks, troubleshooting common issues, look for our follow-up technical deep-dive. 

For Jakarta EE developers running on Payara Platform Enterprise, CRaC represents a way to bring near-instant startup times to enterprise applications without abandoning the frameworks and tools you already know. Whether it makes sense for your specific situation depends on your architecture, infrastructure, and whether startup time is a problem worth solving. 

Payara Micro Enterprise 6.33.0 includes technical preview support for CRaC. Request a free trial to evaluate it with your applications.