News

Proposed Project Addresses Long-Term Java Pain Points

• By John K. Waters
• April 29, 2020

A new project just proposed for consideration on the OpenJDK mailing list would address the "long-term pain points" of Java's slow startup time, slow time to peak performance and large footprint.

Submitted this week in a call for discussion by Mark Reinhold, chief architect of Oracle's Java Platform Group, "Project Leyden" would address these pain points by introducing the concept of "static images" to the Java Platform and  the JDK.

A static image is a standalone program, Reinhold explained, derived from an application that runs that application and no other. A static image is "a closed world," he said, meaning it can't load classes from outside the image or spin new bytecodes at run time.

These two constraints, Reinhold argues, would enable build-time analyses that could remove unused classes and identify class initializers that could be run at build time, which would reduce both the size of the image and its startup time.  They would also enable aggressive ahead-of-time (AOT) compilation, which would reduce the image's time to peak performance.

"Static images are not for everyone, due to the closed-world constraint," Reinhold emphasized, "nor are they for every type of application. They often require manual configuration in order to achieve the best results. We do, however, expect the results to be worthwhile in important deployment scenarios, such as small, embedded devices and the cloud."

Project Leyden would take inspiration from past efforts, Reinhold said, including the GNU Compiler for Java (no longer maintained), which compiles Java source code to JVM bytecode, and the Native Image feature of GraalVM, which supports AOT compilation of Java code to a standalone executable called a "native image."

Leyden would initially add static images to the Java Platform specification, and that change in the spec would eventually be implemented in GraalVM. Developers who use only the standard, specified static-image feature will then be able to switch easily between Leyden (in the JDK), Native Image (in GraalVM), and any other conforming implementations that may arise, choosing among the tradeoffs of compile time, startup time and image size.

"We do not intend to implement Leyden by merging the Native Image code from GraalVM into the JDK," Reinhold said. "Leyden will, rather, be based upon existing components in the JDK, such as the HotSpot JVM, the jaotc AOT compiler (JEP 295), application class-data sharing (JEP 310), and the jlink linking tool (JEP 282)."

Reinhold wants to lead the project with a group of initial reviewers; he suggested Alex Buckley, Bob Vandette, Claes Redestad, Igor Veresov, Ioi Lam, Mandy Chung and Vladimir Kozlov, potentially among others. And he would start the project with a clone of the current JDK release (JDK 15) and track main-line releases going forward. The features of Leyden would be delivered over time in a series of JEPs that would likely span multiple feature releases, he said.