Re: [jakarta.ee-spec] [DISCUSSION] Creation+Plan Review for Jakarta CRaC

[Gerrit Grunwald <ggrunwald@xxxxxxxx>]

Hi there,

let me try to answer your questions...

1. 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.
2. 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.
3. The "Many of" refers to Open Liberty, WebSphere Liberty, Helidon, Payara.
4. -
5. 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

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: Montag, 12. Oktober 2026 04:17
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.

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

 

From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> On Behalf Of David Blevins via jakarta.ee-spec
Sent: Friday, October 9, 2026 6:19 AM
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: David Blevins <dblevins@xxxxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] [DISCUSSION] Creation+Plan Review for Jakarta CRaC

 

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

 

Gesendet: Donnerstag, 8. Oktober 2026 um 21:34

Von: "David Blevins via jakarta.ee-spec" <jakarta.ee-spec@xxxxxxxxxxx>

An: jakarta.ee-spec@xxxxxxxxxxx

CC: "David Blevins" <dblevins@xxxxxxxxxxxxx>

Betreff: [jakarta.ee-spec] [DISCUSSION] Creation+Plan Review for Jakarta CRaC

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