Compiling Java into native binaries with Graal and Mill

https://mill-build.org/blog/7-graal-native-executables.html

by lihaoyi • 1 year ago

154 99 1 year ago

p2detar4• 1 year ago

Graal can only create native binaries targeting the system on which it is running. That means that if you want to create binaries for {Linux,Windows,Mac}x{Intel,ARM}, you need 6 different machines in order to build the 6 binaries and somehow aggregate them together for publication or deployment. This is not a blocker, but can definitely be inconvenient v.s. some other toolchains which allow you to build native binaries for all targets on a single machine.

To me this is a huge downside. One of the reasons I like Go so much is that I can build binaries for any platform I want to support on my Mac or with Docker.

jeswin• 1 year ago

To me this is a huge downside. One of the reasons I like Go

C# with NativeAOT might be an easier path for Java developers. Some might like the expressiveness as well over Go.

pragmatick3• 1 year ago

I don't think you'd be a Java developer anymore.

brabel2• 1 year ago

I've been using Dart instead. Not too far from Java, but can compile to executable without any cerimony.

josefx2• 1 year ago

How is the cross platform UI situation on C#? Anything official?

cratermoon2• 1 year ago

this is a huge downside. Also the compiler can only do static analysis and code generation. I'd much rather a hotspot VM analyze the running code and identify the optimizations on the fly.

Yasuraka• 1 year ago

I'd much rather a hotspot VM analyze the running code

wasting gigabytes of ram and fast startup times

and identify the optimizations on the fly

and still get gapped by statically compiled languages.

I guess these are a cheap price to pay for the benefit of ... having to install and patch runtimes.

tannhaeuser2• 1 year ago

What's your point? This is what the regular JVM/HotSpot has been doing for ages (and GraalVM, too). Whereas native-image does AOT, with optional profile-guided optimization to identify hotspots on the fly.

taurknaut• 1 year ago

Agreed, this is definitely an odd and very unnecessary constraint on builds.

sgammon17• 1 year ago

Well, it's also not true. But aside from that, plenty of software builds in its native environment. Cross-compiling is straight up hard for many toolchains.

flakes• 1 year ago

I wonder if you could wrap this process in something like qemu for a cross-architecture build setup?

taraparo• 1 year ago

You can e. g. create ARM builds on x86 using qemu but the compilation takes ages.

rixed2• 1 year ago

GCJ could do that, as well as JET I believe, but both are long dead.

The history of native compilation for java I find fascinating: Nothing looks like a normal, boring programming language as much as java, yet somehow it resists being treated as a normal, boring programming language, and needs its own galaxy of special idioms and tools, like it was some smalltalk or lisp.

chii3• 1 year ago

because java is not designed for it. It's retrofitted in, because of trends.

There's actually, imho, no need for native compilation for java tbh. Why isn't shipping the runtime with the code a more common practise? it's how intellij or eclipse worked. People today ship electron apps for god sakes!

If you _need_ native, for one reason or another and it's non-negotiable, then choose a native compiled language.

lmz3• 1 year ago

Once you have reflection that's basically eval() so just LISP with worse ergonomics.

josefx2• 1 year ago

GCJ could do that

Was it actually any good? My only experience with it was Debian using it as default Java interpreter, which meant that any attempt to execute Java without first removing it resulted in untold amounts of suffering.

pragmatick3• 1 year ago

While I agree I think most use cases aren't for releasing end-user software that needs to run on many architectures and OSes but rather building enterprise software for one certain combination, usually x86 and linux, to deploy on a server or containerized in a hyperscaler.

But to contradict myself, I actually use windows, WSL and oracle cloud to build for windows x86, linux x86 and linux ARM64 to build a java desktop application. Of course I'd prefer it if I could just use my main machine and OS to build all those like Go can.

ltbarcly3• 1 year ago

You realize you can run Linux, Windows, Mac x intel, arm builds on docker right? Right on your Mac.

sgammon17• 1 year ago

https://github.com/oracle/graal/issues/8350

Plz upvote

sgammon17• 1 year ago

Also, I don't believe this is fully true. GraalVM depends on the underlying C compiler to generate native code, so if properly configured with target triples and flags (just like any cross-compiling setup) it should work.

gf0003• 1 year ago

GraalVM reuses the normal java class loading logic which is platform-dependent. So e.g. on windows it will load some windows-specific File subclasses and the like, so this is more of an architectural problem to a certain degree.

(It really does loadClass everything reachable based on the code to be compiled)

ludovicianul2• 1 year ago

You can do the same with GraalVM on Mac for Java.

theflyinghorse• 1 year ago

Mill looks like an interesting option to try all around.

wiradikusuma• 1 year ago

"Almost every Java program, library, and framework uses some degree of reflection and dynamic classloading, and so you do have to spend the effort to configure Graal appropriately." -- this is by far the biggest problem with native binary compilation.

Imagine spending 15+ minutes building an exe, and it stopping at minute 15 because some things needed to be added in the config. Or, after waiting 30 minutes to have the exe ready, it refused to run because of the same problem.

The issue is we don't know what we don't know. You don't "forget to include something" because you don't know what to include (and even after seeing the error, you still don't lol).

I just wished all 3rd party libraries put their "include this config to include my lib in your exe", just like OSGi manifest (https://www.ibm.com/docs/en/wasdtfe?topic=overview-osgi-bund...).

For example, an issue still open for almost 2 years: https://github.com/firebase/firebase-admin-java/issues/800

killingtime743• 1 year ago

We've been using it at work for a few years. A cli tool, builds in about 6 minutes. We compile it to Linux, Mac ARM and Mac Intel. You're correct about configuring libraries but I found those to be the minority. Most work without configuration. I do this because I will not use Golang if given a choice and Rust is not allowed.

Jabihjo• 1 year ago

What's your issue with Golang? (Not hating, just curious)

pjmlp11• 1 year ago

I am on the same boat, JVM, .NET and nodejs ecosystems before Go.

So many languages, tools and libraries to chose from, without the "simple minds" culture, even C manages to be more feature rich.

sgammon17• 1 year ago

Builds have been slow for a long time via Native Image, but make sure you upgrade to the latest because it has gotten much faster lately. They've also worked hard on binary size.

A pure Java hello world now compiles in a few seconds on a commodity machine and weighs in at about 9mb.

Also, make sure you enable `-Ob` on newer versions of GraalVM, which significantly speeds up build times.

nomercy400• 1 year ago

How do you compile to multiple platforms? Do you have separate machines for each platform?

Do you use any cli library in front? Is 12-20mb acceptable for a cli executable?

Working on a cli tool poc for work here, hence the interest.

jojohohanon• 1 year ago

So springboot and injection does a lot of this; searching the list of known classes for a suitable candidate for injection.

But it’s dynamic by implementation only; to alleviate what came before which was a tedious manual enumeration in xml of those same discoveries.

Presumably we could ask springboot’s discovery to output exactly those finding and the remove the introspection.

mrkeen• 1 year ago

But to be clear, tedious manual XML configuration was also Spring. Others may have done it earlier, but Spring still decided it was the way to go, put their name on it, and released it.

sgammon17• 1 year ago

You have described Micronaut

lmz3• 1 year ago

They already have such a thing https://docs.spring.io/spring-boot/maven-plugin/aot.html

pjmlp11• 1 year ago

This has been a solved problem since Exclesior JET in the 2000's, via agents and PGO, nowadays sadly gone because they no longer can compete with free beer GrallVM and OpenJ9.

https://en.wikipedia.org/wiki/Excelsior_JET

Also ART takes the best of both worlds, as they quickly learned the best is to have JIT/AOT compiler collaborating, thus AOT gets all the reflection related info from the JIT, or Play Store Baseline Profiles and has all it needs to produce a proper AOT binary with the relevant execution flows.

To note that Java and .NET to some extent are catching up to Eiffel, Oberon, Smalltalk and Common Lisp toolchains, of a mix JIT/AOT, while inovating on their own ways as well.

hn8726• 1 year ago

I think https://openjdk.org/jeps/8335368 and https://openjdk.org/jeps/8325147 are two recent JEPs that try to introduce something similar to Google's baseline profiles

sgammon17• 1 year ago

GraalVM also has an agent for Gradle and Maven which can do this.

SamInTheShell• 1 year ago

I think you misunderstand the free beer quote because those tools are free as in freedom not as free beer.

Competing looks like starting with what other people are already doing and making it better.

tannhaeuser2• 1 year ago

I guess Quarkus and Spring 3 native are meant for bringing existing apps to serverless deployments and fast startup times (plus process-level isolation as an option?), but it's true there are also new apps being developed using Quarkus. The investment in tooling, inertia of the ecosystem of third-party libs, and predominance of traditional JIT over AOT deployments must be the reason why they're not just doing away with Spring's reflection in the first place.

sgammon17• 1 year ago

Micronaut is essentially Spring anyway, but with build-time codegen instead of classpath scanning and runtime annotation processing.

It even has a compat layer, and like Quarkus it supports GraalVM out of the box, with minimal reflection at runtime.

https://micronaut-projects.github.io/micronaut-spring/5.9.0/...

sgammon17• 1 year ago

https://github.com/java-native-access/jna/pull/1608

Much of this configuration could be automatic if more attention were given to GraalVM by library authors.

ludovicianul2• 1 year ago

I've built several apps that compile to binary across multiple platforms. The ecosystem is quite mature now, especially if you start from scratch and use things like Quarkus, Helidon or Springboot 3.x. There are *very few* libraries that might need special config.

littlecranky67• 1 year ago

""Almost every Java program, library, and framework uses some degree of reflection and dynamic classloading" - The .NET framework faced the same issues, and much of their ahead-of-time compilation efforts were removing all those API calls to reflection/introspection calls from the base class library. Years of effort and it is still not 100% there yet - I wouldn't count that this is a lot easier in Javaland.

neonsunset6• 1 year ago

  dotnet publish /p:PublishAot=true

Alifatisk• 1 year ago

Will this produce a cross-platform standalone binary?

diggan2• 1 year ago

No, and neither will one invocation of GraalVM.

pjmlp11• 1 year ago

If the dependencies are written with AOT in mind, otherwise plenty of errors will show up.

Also it isn't that easy if any of GUI frameworks from Microsoft are being used.

Ah, and if using WinUI, one even has the additional requirement that only UI elements implemented with partial classes can be AOT compiled due to WinUI magic code.

metaltyphoon• 1 year ago

If the dependencies

There needs to be more context here. I think the BCL is fully annotated already. Many of MS libraries are too including gRPC.

Rohansi• 1 year ago

I don't know why anyone even uses the GUI frameworks from Microsoft these days. WinForms is only good if you need to throw something together quick. Everything else should be Avalonia (https://avaloniaui.net/). Cross platform and does support AOT.

dkjaudyeqooe2• 1 year ago

I'm under the impression that the Community Edition version of GraalVM is neutered by a limited garbage collector and some other limitations when producing native binaries.

Anyone know if this true?

quikoa• 1 year ago

Could Oracle neuter it more in an update to push the commercial edition?

sabas123• 1 year ago

IIRC there base kit like garbage collector and runtime are all the same between community and enterprise. The biggest feature that comes to mind that is behind the enterprise-only wall (or at least used to be) is Profile Guided optimization.

sgammon17• 1 year ago

This is partly true. CE has the "serial GC," yes, and no access to G1 GC by default. But Oracle GraalVM (formerly "GraalVM Enterprise Edition," which no longer exists) was released under a much less restrictive license:

https://blogs.oracle.com/java/post/graalvm-free-license

So, yes, GraalVM CE is slightly nerfed (the performance difference across all EE features is like 30% maximum, at peak, in limited circumstances). You also do not need to use GraalVM CE in as many places anymore, and Oracle GraalVM with G1 is a free download. Many free projects like Pkl use the full-blown VM.

https://www.graalvm.org/latest/reference-manual/native-image...

Serial GC is still very performant. It's great for things like command line tools which don't need a low-pause long-running GC like G1.

dkjaudyeqooe2• 1 year ago

So the runtime and libraies incorporated into native applications compiled by Oracle GraalVM is freely licensed? I tried to find that information but it's all a sea of legalese.

neuroelectron2• 1 year ago

Java had a huge reflection exploit a long time ago and most places blacklisted that library as a result so not a big loss there.

neuroelectron2• 1 year ago

Well, wow. Apparently people are still blindly using reflection. A lot of people, in fact. Have you thought about literally any other language to build services?

rf15• 1 year ago

It's less a problem of the language and more of popular frameworks using reflections excessively. (usually for no gain other than creating platforms that are not controlled by normal readable/tracable code flow but annotations)

Compiling Java into native binaries with Graal and Mill

Related Stories