Hacker News Reader

Comment by zorr | Hacker News Reader

GraalVM is interesting technology. I've been playing a little bit with native-image in a Kotlin project and it allows me to build native binaries from my Kotlin code. With support for a lot of the existing java/kotlin library ecosystem.

The binaries are a bit large (10MB for a Kotlin hello world) but they are fast. I'll be using this for some personal cli tools since Kotlin+Maven is my personal 10x platform.

Besides cli projects I've also done some experimentation with GUI and database stuff. Using the Gluon plugin GraalVM is able to compile a native binary for a JavaFX app that talks to a Sqlite database.

When using a library that relies on reflection there might be some graalvm config to fiddle with but mostly it just works, and some of the libraries are already "native-image ready" with the necessary config inside the published package.

View on HN

Have you tried taking a look at UPX for the binary size? I found that it significantly decreased the size of the binary to the point where the problem was more the size of my dependencies (large JARs that could not be optimized away) and could get the binary to a completely manageable place. They aren't C small, but they were definitely better than traditional Java apps by an order of magnitude.

I had not heard of UPX until just now and just did a quick test. With `-7` level it brings the 10MB binary down to 3.6MB but execution time was roughly x10.

I haven't touched this in a long-while, but I believe startup will be impacted but post startup the impact should be smaller once the binary has been loaded. It depends on how your executable is used of course, but a hello world application will show the worst performance degredation since the code is loaded then executed once.

UPX used to be great when reading from disk took way too long... and having small binaries to read from disk and unpacking in memory was faster... but now in the age of SSDs, I don't know how much sense it makes to compress binaries.

Back in the day, I used to use UPX on most apps, which would greatly improve launch times.

Execution time should hardly be affected in any measurable way, except for trivial scripts.

UPX doesn't play nice with antivirus software if it's important for you to run on Windows (at least).

https://github.com/upx/upx/issues/337

How smooth is JavaFX compilation to native? Any bugs/issues running the native version of JavaFX UI application?

Thanks

native-image takes a minute to compile the binary from the jar but after that it's pretty smooth. I noticed my css styles where a bit different here and there but that could be due to differences in the default stylesheet used in my jvm build (OpenJDK with OpenJFX) vs the native-image build (using Gluon and maybe a customized JavaFX version)

That's awesome to hear! If you could share any working Hello World repos or similar using Gluon and SQLite I would massively appreciate it. About 5 years ago I developed a GUI desktop app with TornadoFX, Spring Boot and SQLite and it turned out to be incredibly solid, and I've always wanted to go back and try to find out a quick template repo with Gluon to try and do more small desktop apps again.

I'm working on it but nothing to share yet. I think Gluon itself has a few starter/example projects. The Xerial sqlite library already has native-image configuration files in its build so no extra config required. I'm still trying to get Jdbi to work fully with native-image and once that is done I will create a PR there. But my time is limited in the next week or two.

Also, I'm using plain JavaFX with Kotlin instead of TornadoFX. Mostly because I'm not sure about the health of the TornadoFX project and I don't like some of its abstractions.

Isn’t Tornado stuck on Java 8?

Do you have a link to any example repos by chance? The need has slowly been growing for some cli tools I want to write, but I haven't taken the plunge yet. I'm the most curious about peeking at your maven setup.

I don't have anything public right now but the setup is pretty simple (although I use Gradle with the Kotlin DSL instead of Maven). It's your standard kotlin or java setup that can build a jar with dependencies included, and 1 extra build step to invoke `native-image` from the Graal SDK.

https://github.com/pvorb/graalvm-kotlin-native-image-sample

Is Jetbrains Desktop Compose Graal compatible ?

https://www.jetbrains.com/lp/compose-desktop/

Reply on news.ycombinator.com