Hacker News Reader

Comment by serbuvlad | Hacker News Reader

Very funny to me that Java's initial appeal: it's easy to deploy "everywhere"; is now it's disadvantage (you need a whole Java setup with JAVA_HOME and God knows what else).

Now the bar for GUI apps is cross-compilation to deployable web, Windows, Linux (Electron), Android, iOS (? I don't know I don't use/develop for Apple products) versions from running a simple command.

And for the CLI world, well, almost everyone is on Linux x86-64, or maybe arm, so a few static binaries (or "virtually" static -- depending only on glibc) are king for deployment.

View on HN

I don’t find installing a JVM a massive amount of work (no more so than any other interpreted language), but nowadays you can AOT compile Java to a native binary if that’s your hang-up:

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

There’s a new LTS release with improvements coming out next week.

Half the battle is figuring out which JDK (or is it JRE??) version to install. I still have nightmares navigating the maze which is Oracle's site and trying to find the right download, only to have installed the wrong thing.

Installing the latest OpenJDK LTS release will almost certainly work for you. Java is pretty good about backwards compatibility. I'm not sure when you last tried, but you probably don't need to muck around with Oracle JDK builds at at all.

It's not as painless as you make it seem though. Among other things, the compiler needs to know reflectively accessed program elements ahead-of-time.

Unfortunately people writing libraries do all kinds of things just because they can and as such I've almost never been able to just simply AOT compile something without more manual efforts.

There are trade-offs using Native Image, for sure. Part of eliminating the JVM is that you won't have the JVM at runtime so you can dynamically load classes. Consequently you need to AOT compile any code you'd dynamically load as well. Release-over-release the tooling and support for dealing with reflection have become more user friendly. More of it is auto-detected during native image build and the remainder can be generated by a runtime agent (at least in my experience). I expect it'll be even easier with the new 25 release.

We've been shipping TruffleRuby as native image builds for years. Other Truffle languages have as well. And it's been quite popular with microservice frameworks. Recently I saw someone on the GraalVM Slack say they AOT compiled a large JavaFX application.

It's work, but probably far less than a rewrite in another language and the tooling is getting better. Obviously I can't speak to your experience, but if you haven't looked at it in a while it might be worth giving newer releases a shot.

Thank you for the insight. It has been a while and now I do want to give it a try again! Maybe it could be nice for small CLI applications instead of using Go.

How is it performance wise? Are there some big things/roadblocks to be aware of?

Reply on news.ycombinator.com