JEP 544: Ahead-of-Time Code Compilation

I'm speaking more from my view as just an individual Joe Sixpack developer. If I'm not developing an enterprise behemoth, and let's just say I want to whip up a command line utility to do some image processing, or network communication, etc, Java's fantastic standard lib and ecosystem means I can do all of that pretty easily. But when I want to distribute that, what does it look like? What comes out the other side of the CI build? I have to integrate jlink with gradle, which is kind of a pain, I have to somehow integrate a training run and then package up the aot cache output and make sure that the directories are handled properly, and what do I ship to the user? A tar/zip file that they have to somehow copy and decompress to the relevant directory, maybe with #! file in .local/bin to get it on the path? By contrast the situation with Go or Rust is immensely easier, even if that actual development process may almost be harder because I have to spend time faffing about deciding which image library to pull in for Go, or dealing with async for Rust. But once that is actually done, I just ship the binary and simply copy it somewhere to get it on the path, and I never have to worry about reading gradle/maven docs or anything like that.

So I'll finish by saying that my ideal build tool is probably not a great one. What it is crucially is a simple one. I think that's that gap right now, that Java has these huge, immensely powerful and general build tools, build tools that I am guessing eventually gain equivalents in the Rust and Go worlds when projects grow old and gnarly enough to require a bunch of custom build stuff, but it doesn't have baby's first build tool like go build and cargo, where you can just get an idea and start building and come out the other side with an artifact and 0 time spent on thinking about the build system, until you actually need the kind of complexity that maven and gradle provide. Give me a build tool that assumes the standard src/ and test/ directory layout, then builds everything into some sort of archive file, creates a minimized JRE to run it, accepts an argument for an aot.cache file location, or for the more difficult option runs the program to generate that file and then bundles it up with the archive, bundles all the libraries that I've pulled into the project up into the archive along with all the resources declared for the project as well, and then spits out a single file artifact that I can immediately use and run. Give me a build tool that I don't even realize is there until I actually need that complexity.

I understand if this is vague and not a great answer, and I also appreciate all the work you've done for the Java community, so thanks for replying.

I’m sure that all of this stuff can be strung together after spending a suitable amount of time trolling through the documentation of the individual tools, but it’s far cry from go build and cargo build, and I think it would be great if Java could narrow the gap in this aspect.

Yes, and that’s a significant limitation in the Java library and framework ecosystem.

What is the objective here? Startup latency or throughput? Both will be vastly improved by JEP 544.

Excelsior JET wasn't the only commercial vendor, only one example, there were others, two surviving ones are PTC and Aicas, meanwhile IBM open sourced Websphere Real Time JVM AOT as part of Open J9.

A big difference between .NET and Java world, is that since early days Sun licensed the technology, thus the ecosystem is like C and C++, with plenty of options to choose from, each with its own set of JIT, AOT and GC flavours.

Even Android, while not being Java, has had JIT cache + AOT since Android 7, after trying to be pure AOT on Android 5, when Dalvik was replaced by ART.

.NET has had NGEN since day one, however it has been rather basic in optimizations, designed for quick startup of Windows Forms applications and little else.

Sing# and System C# were quite interesting, but they never left Microsoft Research into regular .NET.

Mono was the one caring about proper AOT compilation and JIT caches, then .NET Native was created by the Windows team which was more interested into using COM to replace what was left of .NET on Windows since Longhorn than anything else.

Java and .NET only started caring about offering free beer AOT compilation, JIT caches, due to return of AOT compiled languages and the adoption competition in the server room from those languages.

Ideally, they should have supported proper AOT compilation, and value types (in Java's case) since day one, given languages like Oberon, Modula-3 or Eiffel, that predated them.

Instead, both platforms are now catching up with those 1990's languages.