For a few months now I’ve been pondering, and brainstorming with a few
of you, how best to frame the work of Project Leyden conceptually.
Here’s my proposal:
https://openjdk.org/projects/leyden/notes/02-shift-and-constrain
Short summary:
The goal of Project Leyden is to improve the startup time, time to
peak performance, and footprint of Java programs. In this note we
propose to work toward that goal by extending the Java programming
model with features for _selectively shifting and constraining
computation_ by means of _condensing code_. We also propose an
initial research and development roadmap.
Comments, questions, and suggestions welcome!
- Mark
HI!
This is my first posting here, so please bear with me.
The proposal gives two reasons why working with static executables is inconvenient. These reasons may have influenced the decision to delay the standardizing of static executables in favor of optimizing Java first. I'm not sure how valid these two reasons will be when the first results of Leyden become broadly available in three years. So I'd like to get your feedback!
I assume 95+% of users run LTS Java releases in production (https://youtu.be/SYO-LmA647E?t=186) Leyden won't be in Java 21 but will ship (at least partially) in Java 25.
The first reason was that static executables require "developers to construct and maintain fragile configuration files". We need these configuration files if a library doesn't work with static executables out of the box and our Java framework can't configure that library (GraalVM strongly recommends using a framework for static executables). Or if our own code does something neither GraalVM nor the framework can figure out. The libraries shipping with GraalVM-supporting Java frameworks work, so this compatibility issue is mainly about that "random library from Maven Central".
VMware announced last year that Spring Boot 3 will support GraalVM static executables. I think that'll tremendously increase the compatibility of the Java ecosystem with static executables. Why? Because everybody wants to integrate with Spring Boot.
And compatibility is now a community effort: GraalVM, Spring, and Micronaut launched the GraalVM Reachability Metadata Repository. Helidon may join soon, according to its lead. And since everybody can contribute reachability data, this is now even partially crowd-sourced.
Will that work perfectly next month with Spring Boot 3? Nope. Will it be good enough for most new projects with Spring Boot 3.6/4.0 in 3 years? I believe so. Now, this is just my opinion. So, how do other people predict the degree of static executable compatibility in Java in three years?
BTW: Spring Boot can use Java method calls and annotations for configuring static executables, not "fragile configuration files" (https://www.youtube.com/watch?v=TS4DpYSmfXk&t=2307s)
The second reason is that developers "endure unusually long build times" with GraalVM static executables. Unusually long build times? Yes. Developers? Not so often. Why?
Because the best practice seems to be to NOT work with static executables during development but use Java instead. I think this mirrors Java development for Kubernetes, where it's often impractical to run a whole Kubernetes cluster with all the nodes and all the data on the developer's machine. The difference between "local Java" and "running application" is more significant with static executables, but it appears manageable for daily development.
In that approach, it's generally the CI/CD pipeline that builds static executables. Developers only build static executables "before a significant feature is about to be merged or when a problem arises that requires debugging", to quote a "lessons learned from using static executables" InfoQ article I edited (https://www.infoq.com/articles/native-java-real-world)
So it seems long build times are mostly not an issue today and will be even less so in three years: At least so far, static executable build times have decreased continuously with GraalVM releases.
Now, I have just one data point with my article. What does everybody else think about the impact of build times on static executables?
Regards,
Karsten Silz