|
Hi Kenji,
Ok here you go, let's assume your application is using microservices and you need to scale those services from time to time depending on the load. If your app is running on a Jakarta EE based app server, the startup time of your service might be within 5-10
seconds. This is not really great if you would like to serve your customers as quickly as possible. In such a scenario startup time is king and the shorter the better. With CRaC you can bring the startup down to 1 second and even below (which is the reason
why other frameworks like SpringBoot, Micronaut and Helidon also support CRaC).
In short everywhere you need a fast startup of your application CRaC can help.
The idea is to have two options to create checkpoints, the first option is to let the app server automatically create the checkpoint directly after it was started and right before the application code will loaded. This could already save up to 80% of the startup
time depending on the application size. In this case the user doesn't have to do anything because the application code isn't even loaded at that point.
The second option would be a manual checkpoint that is triggered by the user from the outside of the JVM by using jcmd. In this case you as a user can decide when to create the checkpoint of the application. You might ask yourself why does this make sense?
Well if you have an application that takes some time to warm up, you first can warm it up in your CI/CD pipeline and then create the checkpoint. In production you restore it from this checkpoint and the application will continue running from there within 1
second. The second option might need some changes in the code but will give you the fastest possible startup to a completely warmed up application.
To your last point...this is exactly why CRaC needs to be implemented by the application server. In case the application server supports CRaC, it can take care of closing and re-opening resources like JDBC connections. And to make sure everything is implemented
in a compatible way, a Jakarta EE specification for CRaC makes sense.
I hope that helped you in understanding the project better.
Kind regards,
Gerrit
Gerrit Grunwald
Senior Developer Advocate
E: ggrunwald@xxxxxxxx
M: +49 171 1745350
Von: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> im Auftrag von Kenji Kazumura (Fujitsu) via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Gesendet: Dienstag, 13. Oktober 2026 06:35
An: 'Jakarta specification discussions' <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Kenji Kazumura (Fujitsu) <kzr@xxxxxxxxxxx>
Betreff: Re: [jakarta.ee-spec] [DISCUSSION] Creation+Plan Review for Jakarta CRaC
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
Thanks for response.
Could you provide realistic use cases or practical examples that make it clear what value this specification would offer users,
based on the following assumptions?
* The problem this specification is trying to solve is startup time.
* Most of the startup time is the time spent starting and initializing the application server.
* User applications also use resources such as JDBC connections, but those are usually managed by the application server.
-Kenji Kazumura
From: Gerrit Grunwald <ggrunwald@xxxxxxxx>
Sent: Monday, October 12, 2026 5:49 PM
To: 'Jakarta specification discussions' <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Kazumura, Kenji <kzr@xxxxxxxxxxx>
Subject: AW: [jakarta.ee-spec] [DISCUSSION] Creation+Plan Review for Jakarta CRaC
Hi there,
let me try to answer your questions...
- The OpenJDK CRaC project is focused on getting support for Checkpoint-Restore on JVM level. Meaning to say the JVM should be capable of being able to handle
a checkpoint and a restore triggered for example by jcmd. This is the basic functionality which is needed to be able to checkpoint a running application in a JVM and restore it afterwards from the checkpoint. The main problem with for example CRIU is that
it was made to checkpoint/restore programs/containers but not Java programs running within a JVM. CRIU can checkpoint the JVM itself (as a program) but your application that is running within this JVM has no idea that the JVM was checkpointed or restored.
This leads to the fact that resources that are opened by your application (e.g. a socket connection or a file) cannot be closed when it comes to a checkpoint because your app has no idea about the checkpoint and it can also not be restored because of the same
reason. The OpenJDK CRaC project tries to solve exactly this problem, it provides a way to let your application know when it is checkpointed and restored. Application servers like OpenLiberty, Payara etc. are itself programs running on a JVM and within these
application servers the business application is running. So we have another layer of abstraction here, if the application server now can handle checkpoint/restore events by implementing the CRaC Resource interface, the business application will still fail
at checkpoint-restore because again it has no idea. For exactly this reason it is needed that the application server informs the running business application in case of a checkpoint and restore so it is able to handle it properly (closing/re-opening resources
it needs). I hope that explains the difference between the CRaC OpenJDK project and the JakartaEE spec.
- The reason is the same, as the first one, the OpenJDK CRaC project handles the checkpoint/restore events on JVM level, the JakartaEE spec handles them on framework
level. The JakartaEE spec is needed to make sure that all application server vendors implement the CRaC event handling the same way to make it as easy as possible to change between vendors.
- The "Many of" refers to Open Liberty, WebSphere Liberty, Helidon, Payara.
- The benefits this specification offers are mainly to make it as easy as possible for the user to change between vendors even when using CRaC. At the moment
OpenLiberty, Helidon and Payara are already supporting CRaC in one way or the other but they all use different implementations which needs the user to adapt the code base to a vendor specific implementation. In case of having a spec for CRaC, the vendors will
make sure that the implementation conforms to the spec and the user can easily switch between different vendors which is one of the main benefits of having specs at all in JakartaEE I think.
I hope this helps to better understand the idea behind the JakartaEE CRaC specification.
Kind regards,
Gerrit
|
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the
sender and know the content is safe.
|
I also have a few questions, which I submitted to GitLab (https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/work_items/1399#note_8631094),
but I move them to this thread.
[Original questions submitted to GitLab]
(1) Please explain the differences and relationship between this project and the OpenJDK CRaC project (https://openjdk.org/projects/crac/).
(2) Please explain why this must be the Jakarta EE specification rather than the Java SE specification.
(3) Regarding the background, please clarify exactly how many
“Many of” refers to.
(4) Please explain why the Patent License must be an Implementation Patent License.
(5) This specification seems to be used by application server vendors. Please explain what benefits standardizing this specification would offer
to users of Jakarta EE.
Ivar gave me an answer (https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/work_items/1399#note_8636375),
but I still didn't quite understand the benefits of standardization for end users.
I understand that using CRIU allows application server vendors to provide values to users.
However, it seems to me that this is dependent on the vendor's implementation.
If there is a requirement for users to interact with CRIU directly from their programs,
I'm not clear the reason that it would be better to define that in Jakarta EE rather than in the Java SE or JDK specifications.
-Kenji Kazumura
To be clear, I'm not making a point but asking questions. I have no formed opinion on where or how. Just questions at this point.
If we are imaging creating API classes, we should create a spec. If we only intend on producing requirements and tests, maybe going the route platform requirements plus requirements in individual specs is more apt.
That said, there still might be reasons for a spec -- would just want to identify them first.
Either way, the need for the work is clear and we're on board with a CRaC requirement in Jakarta EE. The most ideal outcome is that we're all required to run all TCK tests for all specs on a CRaC snapshot.
-David
On Oct 8, 2026, at 1:56 PM, Werner Keil via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
wrote:
Hi,
I already voted in favor, but David certainly has a point.
CRaC is quite a lower-level technology and it was originally an OpenJDK project, or still is:
https://openjdk.org/projects/crac/
So how did it end up a Jakarta proposal and not say under Eclipse Adoptium?
Werner
Hi All!
First a quick note that though our process doesn't require discussion on this list before votes, I personally find it helpful. I suspect there was some discussion by those that can attend the Tuesday platform calls.
Fully on board with the base concept that we should support CRaC.
Handful of questions and musings. None of them should be interpreted as a preference or blocking. We don't need to have all the answers. Just trying to get a pulse.
CRaC is defined externally, which is a pattern we've seen before in basically two shapes.
CORBA for example was leveraged in the Java EE specs and EJB specs. But we didn't have a "Java CORBA" spec specifically. This made sense as we didn't produce any java libraries people would code against. Our goal was just to create rules and tests to guarantee
CORBA was supported. The work then was done in the individual specs and platform spec.
SOAP as a different pattern, though defined externally, did not have any bindings in Java so there was quite a bit of work. We both created a spec with API jar to get those bindings right, and then there was work in specific specs like EJB to integrate it there.
CRaC is defined externally and already does have java bindings. Do we imagine adding any new java API for this or would we just leverage the existing API crac.org defines? If we don't imagine producing an API, do we need this as a separate spec or can the requirements
go into a combination of the Platform and individual specs that want to support CRaC?
If we do create a Jakarta CRaC spec, is the term CRaC trademarked?
Do we have thoughts on how we could test people's compliance? In EJB we have session persistence with @PrePassivate and @PostActivate. Neither of them are testing in any Java EE TCK or Jakarta EE TCK. I never cared for that. Do we have thoughts on how we would
not reach the same fate?
Do we have any finger in the wind ideas on when the CRaC snapshot would be taken and retaken? There's a great deal of art to that part of it. I've used the feature and love it. Certainly you can do the pattern of deploy+init the app -> snapshot -> crac start.
More and more I see value in deploy+init the app -> run warm-up load for hot-spotting -> snapshot -> crac start.
Overall, I do want to convey great appreciation for the effort to get this as a requirement.
-David
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
