"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.<p>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.<p>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).<p>I just wished all 3rd party libraries put their "include this config to include my lib in your exe", just like OSGi manifest (<a href="https://www.ibm.com/docs/en/wasdtfe?topic=overview-osgi-bundles" rel="nofollow">https://www.ibm.com/docs/en/wasdtfe?topic=overview-osgi-bund...</a>).<p>For example, an issue still open for almost 2 years: <a href="https://github.com/firebase/firebase-admin-java/issues/800">https://github.com/firebase/firebase-admin-java/issues/800</a>
> 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.<p>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.
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.<p>Anyone know if this true?