Compiling with GraalVM is still a pain and will not work out-of-the-box without modifications for any non-trivial project. This is mostly, I believe, not GraalVM's fault, because it can only do so much within the confines of the existing ecosystem.
If only AoT compilation to native code would have been taken seriously from the start, if only gcj would have gotten more attention, we could have ended up with an ecosystem that is somewhat amenable to what GraalVM tries to do.
As much as I like GraalVM and wish it success, my prediction is that in a few years it will be in the same state gcj has been quite some years now.
Native image is quite different. With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory and start instantly. At a stroke this is resolving one of the biggest complaints people have always had against JVM languages.
And as a consequence you're seeing adoption by the wider community. All the modern Java web frameworks support it now, and there's a metadata repository where it's collected for projects that haven't accepted it upstream yet [1].
You make it sound like GraalVM is just for ahead-of-time compiling like gcj, but there's more to it than native image. It's possible GraalVM will be openjdk's jit compiler, for example.
I'll take that bet.
GraalVM has only gotten more and more popular.
There are a lot of situations (large server applications) that don't benefit much from AOT.
But others do. Android is (partially) AOT.
I think in today's ecosystem of microservices and serverless etc, AOT will be taken pretty seriously.
Also Android uses a mix of AOT and JIT since version 5.
How are we people practically putting this polyglot stuff into action?
Distributing a nonmodularized Java Swing app in 2023 is far more difficult than it should be.
It’s great.
ISOLATED and UNTRUSTED require GFTC
CONSTRAINED is also available under open-source licenses.
Only for JavaScript right now. We are working hard on supporting all the other languages!
Developer here. So, if you have more questions, let me know!
I was doing stuff in Clojure. Clojure is a great language but it tends to have very slow startup times, even by JVM standards (it's not weird for a large Clojure program to take 5-6 seconds to start. Even a "hello world" can take upwards of a second or two). Graal mostly Just Worked with the standalone uberjar produced by Leiningen and created an executable that started in about 3 milliseconds. It was amazing.
While the lack of proper reflection support was a little annoying, it actually wasn't as horrible with Clojure as you might think; most problems were fixed with basic type hinting, and all but one Clojure library I used (http-kit) worked flawlessly.
By reordering things to be loaded smartly or lazily, startup speed can be improved a lot.
Another reason for a slow startup is that Clojure must load its own runtime every time. The current compiler is not a tree shaker, nor can it rewrite complex expressions in compile-time, although many clojure.core functions were rewritten over time to accommodate JVM optimizers. However, Graal is here precisely to do at the bytecode level, as long as you take care of all type hint warnings and avoid things Graal can't see during compilation (e.g. deferring evaluation of some expressions for runtime).
Things that broke include: JSON (de)serialization using Jackson, validations using hibernate, validator, AWS SDK, and even simpler libs like picocli...
It could be quite useful for a set of simpler apps though
[0]: https://github.com/remkop/picocli/blob/main/picocli-codegen/...
It's really unfortunate how Java and C# are perceived as slow because of their painful startup time.
If you use a framework like Spring Boot then you don't even need that. Just upgrade to 3+ and Jackson, Hibernate (and maybe these other APIs) should pretty much work out of the box.
https://gist.github.com/chrisseaton/535e0e80ea19803d5529c623...
Specifically:
> GraalVM language runtimes (for JavaScript, Python, Ruby, Java on Truffle, WebAssembly, and LLVM) can now be [...] installed as Maven/Gradle dependencies [...] which will work for GraalVM JDK and any other compatible JDK
Polyglot experimentation just got a whole lot easier! Kudos to everyone involved in pushing the JVM ecosystem forwards.
Wouldn’t this provide massive gains for the Rails ecosystem once delivered?
(And with the GraalVM licenses changes to be more favorable/permission, I have to imagine there would be significant adoption)
TruffleRuby runs Rails and is compatible with many gems, including C extensions. TruffleRuby is not 100% compatible with MRI 3.2 yet. Please report any compatibility issues you might find. TruffleRuby passes around 97% of ruby/spec, more than any other alternative Ruby implementation.
My question is, how viable is TruffleRuby vs JRuby?
https://openjdk.org/jeps/8313278
It is "Ahead of Time Compilation for the Java Virtual Machine". The proposal details of using AOT code at startup and then JIT taking over. So you get best of both worlds with fast application launch and then throughput once things are warmed up.
Graal is cool, but it will not be as throughput performant compared to JIT. Only for fast startup, serverless or low memory environments.
Also, there was a proposal (not yet JEP though) on condensers and that model could also make great use of GraalVM.
This means you can take full advantage of ARM cloud services like AWS Graviton (sp?) services for lower cost.
Also, looks like the Java Vector API (JEP338) has been optimized.
So, same code on your Raspberry Pi and AWS Graviton, cool.
It can't do native images from those though.