News for hackers. Stuff that matters.
Re:Java is fast, code might not be by looperhacks on Friday March 20, 2026 @10:57AM (#47455515)
You can create a native executable with GraalVM. Alternatively, if you want to keep the JVM: With the ongoing project Leyden, you can already "pre-train" some parts of the JVM warm-up, with full AoT code compilation coming some time in the future.
Re:Java is fast, code might not be by Thaxll on Friday March 20, 2026 @12:20PM (#47456810)
GraalVM has a lot of limitations, some popular lib don't work with it. From what I remember anything using reflection is painful to use.
Re:Java is fast, code might not be by senkora on Friday March 20, 2026 @11:03AM (#47455614)
And going the other direction, if you want your C++ binaries to benefit from statistics about how to optimize the steady-state behavior of a long-running process, the analogous technique is profile-guided optimization (PGO).
Re:Java is fast, code might not be by vbezhenar on Friday March 20, 2026 @12:23PM (#47456851)
GraalVM is terrible. Eats gigabytes of memory to compile super simple application. Spends minutes doing that. If you need compiled native app, just use Golang.
Re:Java is fast, code might not be by brabel on Friday March 20, 2026 @01:26PM (#47457762)
I used to be really excited about GraalVM but this, together with limitations in what Java code can run (reflection must be whitelisted - i.e. pain) made me run away from it. I do use Go, but my favourite substitute for Java is actually Dart. It can run as a script, compile to a binary or to a multiplatform "fast" format (a bit like a jar), and performance wise it's par on par with Java! It's faster on some things, a bit slower on other... but in general, compiling to exe makes it extremely fast to start, like Go. I think it even shares some Go binary creation tooling since both are made by Google and I remember when they were implementing the native compiler, they mentioned something about that.
Re:Java is fast, code might not be by gf000 on Saturday March 21, 2026 @03:42AM (#47464903)
But you only need to do that before a release. You can just develop with the normal JVM with ultra fast incremental builds and hot reload.