Azul Proposes Java State API to Speed App Start-up Times

Java platform provider Azul has proposed a new API to help developers get around the long start-up and warm-up times for Java apps by saving the state of the runtime.

Anton Kozlov, a software engineer at Azul, proposed a new API known as Coordinated Restore at Checkpoint (CRaC) to the OpenJDK community. According to Oracle’s Java Platform Group, Azul initially proposed CRaC in 2019 and has renewed its proposal this week.

“Java applications can avoid the long start-up and warm-up by saving the state of the Java runtime (snapshot, checkpoint),” Kozlov wrote. “The saved state is then used to start instances fast (restored). But after the state was saved, the execution environment could change. Also, if multiple instances are started from the saved state simultaneously, they should obtain some uniqueness, and their executions should diverge at some point.”

Kozlov added that a practical way to solve these problems is to make Java applications aware of when the state is saved and restored. Then an application will be able to handle environmental changes, he said.

“OpenJDK is the place where innovation on the Java Platform, Standard Edition takes place,” the Oracle Java Platform Group said in a statement. “This proposal was discussed and presented at the 2019 JVM Language Summit and we welcome seeing more progress being made and that it may be a project at OpenJDK.”

Gil Tene, Chief Technology Officer at Azul, said the company does not yet have a specific Java version targeted for this API and capability. Azul expects to develop CRaC under the JDK Enhancement Proposal (JEP) process and in a project and to propose inclusion in some future OpenJDK and Java SE versions.

CRaC is “the type of feature that Java needs to increase its relevance in the cloud native world.”– Eclipse Foundation’s Mike Milinkovich

“This will obviously not be in 17, and hopefully, will make it in some version that follows,” Tene said. Given the time it usually takes to mature such things, Azul expects it to be no earlier than 19 or 20, “and could be much longer,” he said.

Mike Milinkovich, executive director of the Eclipse Foundation, which is the steward for the Java-based Eclipse IDE among other tools for developers, said he didn’t have any comments on the specific technical proposal. “However, this is the type of feature that Java needs to increase its relevance in the cloud native world. I hope that the OpenJDK community embraces this as an opportunity to drive innovation in the Java platform,” he said.

The CRaC project’s goal is to deliver a Java API for coordination between application and runtime to save and restore the state,” Kozlov wrote.

“Runtime should support multiple ways to save the state: virtual machine snapshot, container snapshot, CRIU project on Linux, etc.,” he said. “We hope to come with an API that is general enough for any underlying mechanism. We also plan to explore safety checks in the API and runtime, which prevent saving the state if it may not be restored or work correctly after the restore.”

Indeed, tools that make developers’ lives better are always welcome, said Holger Mueller, an analyst at Constellation Research.

“It’s always good to see innovations that make developers’ lives better, and recently a lot has been happening in the space, which is good to see, he said. “As developer velocity is key to building better and faster next-generation applications, development tool start-up times and re-finding work have always been a drain on productivity. So, it is good to see a proposal to help Java developers gain a stateful IDE about changing the future of work for developers.”

Meanwhile, Kozlov proposed that he become project lead of the CRaC Project and that “A fork of JDK would be a starting point of this project,” he said.

The fork, however, would not be a “fork” in a bad way, it just means it would have its own separate builds from mainline, just like Oracle’s Valhalla and Panama Java projects, for example, the Oracle Java Platform Group said.

In a post to the OpenJDK maintainers last year, Tene wrote: “In the Java arena, we aim to create a generic CRaC API that would allow applications and/or application frameworks to coordinate with an arbitrary checkpoint/restore mechanism, without being tied to a specific implementation or to the operational means by which checkpointing and restoration is achieved. Such an API would allow application frameworks (e.g., Tomcat, Quarkus, Micronaut, etc.) to perform the needed coordination in a portable way, which would not require coding that is specific to a checkpoint/restore mechanism.”

In that same post, Tene said Azul’s hope is to start a project that will focus on specifying a CRaC API and to provide at least one CRaC-supporting checkpoint/restore OpenJDK implementation with the hope of eventual upstream inclusion in a future OpenJDK version via associated JEPs.

“We would potentially want to include the API in a future Java SE specification as well,” he said.