61–70 of 80 posts
I use Graal Native to AOT compile my JavaFX applications. It works surprisingly well.
it’s time to do a barrel roll
Warning: Graal is owned by a law-firm called Oracle (that happens to employ some programmers too).
I've only done one project with GraalVM and I've been pretty happy with it in regards to faster startup time. 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 uberja…
What are the applications where slow startup time is such a big issue?
Earlier quoted context omitted.
gcj had a lot of problems beyond needing configuration of reflection metadata. It used a full reimplementation of the standard library, and it was never adopted by the wider Java community being largely just Red Hat's strategy for creating a fully open source Java implementation rather than something offering specific benefits to Java developers. In particular people thought it'd lead to faster code, but GCC was neve…
> With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory Source ?
GraalVM is a hugely under-appreciated piece of technology. A lot of my initial interest came from being able to blend different languages into a single runtime via the polyglot APIs, but the combination of performance, strong sandboxing support, and multi-language support has helped it emerge as a key primitive for anyone wishing to build extensible platforms without sacrificing speed, security, or developer ergonomi…
It's fascinating technology, but in my opinion too little, too late. 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 wou…
Distributing a nonmodularized Java Swing app in 2023 is far more difficult than it should be.
I use Graal Native to AOT compile my JavaFX applications. It works surprisingly well.
I was considering this, working on a new javafx app for a side project. Using java 17, and generating binaries with fxlauncher/jpackage/wix is not working great imo. Any good recommendations on tooling for using the graal route? I develop on linux but most users will be on windows. It would be great to not have to use windows vm for building the binaries (but i can if needed ofcourse).
We tried to use it to improve AWS lambda startup times but desisted as it was a pain to use it with an existing app. It required too many tweaks as there are waay too many things that rely on reflection :( 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
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.