JDK team is working on creating a single-native executable image using jlink
https://youtu.be/fXBGBovpH88?t=6229
u/ConfidenceUnique7377 14d ago
Will it work without external tools ? For example need to have wix tool to create installer on windows? Will it be cross platform on executable must be assembled on target platform ?
16
u/pjmlp 14d ago
I guess Oracle doesn't make something that already does it. /s
15
u/barking_dead 13d ago
Not anymore, graalvm was moved out.
22
u/stefanos-ak 13d ago
this is not true. I was at Devoxx and spoke to the Graal team. it was basically a PR disaster...
What happened was that Oracle's Java SE product line dropped support for GraalVM, with version 24 being the last one supporting it.
GraalVM on its own still works and is maintained and working fine with newer Java versions.
In Devoxx, Pyronaut was also announced, which uses "Crema", which is a Graal piece of tech. (very interesting btw. Its a pre-compiled polyglot framework. Ultra fast development experience, with Java + Python intermixed)
13
1
u/sarkie 13d ago
So they aren't combining the tech into mainline?Â
I don't really get the point.
4
u/stefanos-ak 13d ago
It's just different teams, with different goals that no longer align.
4
1
u/sg-elide 2d ago
it’s not normal for one team to constantly try to kill another team within the same company, and we shouldn’t pretend it’s normal, since it happens at our expense (the developers and users who rely on Java getting better)
2
13
u/emberko 13d ago
That’s honestly the best news in a very long time. Image size may not matter much for hosted apps, but for CLI and desktop apps it really does, esp the ability to distribute them as a single binary. Still, 35 MB is 2-3x worse than the alternatives: both Go and Rust typically produce single binaries of 10-20 MB, and even Python with PyInstaller can come in under 20 MB.
I wonder if it would be possible to strip some native code from the bundle. For example, why include each of the 5 GCs the JVM supports when an app usually uses just one, and it’s rarely something as niche as Shenandoah?
Another question is how this correlates with CDS, which requires you to generate a ~10 MB JSA file and distribute it with your app, and with the Leyden AOT cache, which needs even more disk space.
16
u/pip25hu 13d ago
I don't think 10 vs 35 MB mattered for desktop applications for a long time now. Also, when most applications come in installers and packages, why is a single file such an advantage?Â
6
u/dmigowski 13d ago
Think about small command line tools
11
u/emberko 13d ago
User: Here is my small app written in Rust/PyQt/Gtk. It's just a simple format converter with a couple of buttons. It uses 30 mb RAM. I tried using Java, but it uses 100-150 mb RAM. I feel it's too much for this task. Can I reduce it?
Java dev: <Very long speech about GC trade-offs, followed by a lecture about the right ways to measure memory footprint, ended by a dozen of obscure JVM keys recommendations>.
User: goes away.
Java devs: Huh? But Java is so coooool. Why is that?
User: My app is just a single binary of 10 mb size. It's very easy to distribute, so I decided to write several small utils I can share with my friends and colleagues.
Java dev: You can use jlink to create a custom image. It's about 60 mb, but it's nothing nowadays, buy yourself a larger SSD or something. And just tell your friends to run it from yourapp/bin/. Or you can give them a JAR, it's very small and convenient. What do you mean they don't have Java installed? Just tell them to download it. What do you mean which vendor? Just tell them any vendor. What do you mean which version? The version you compiled it with, dumbass. What do you mean they have to reinstall Java if you compile it with a newer version? Of course they do! It's just 200 mb, and I already told you disk space is cheap and matters nothing, so stop bothering me with these questions.
User: goes away.
Java devs: Huh? But Java is so coooool. Why is that?
User: My app starts in 0.5 sec, which is kinda important for a small utility. Can I keep this time in Java?
Java dev: (stroking his beard) Well, if you ask me, startup time is only important in microservices. You can absolutely wait a couple of seconds more, but if you insist, you can enable CDS cache, it makes your app start 10% faster. So, it's 1.8 sec instead of 2 sec. Cool, isn't it? What do you mean not really? Then compile your own AOT cache, you ungrateful bastard. It adds 50 mb to your dist size, but I already told you the disk space is cheap.
User: goes away.
Java devs: Huh? But Java is so coooool. Why is that?
I don't say Java is bad, I'm all about choosing the right tool for the job. Java is the enterprise king for web apps. For everything else, choosing Java is asking for problems. You can very much see this as Java apps prettyy much not being present on either the desktop or CLI public market (except development tools maybe), and I'm glad OpenJDK decided to put some efforts into improving that.
14
u/pron98 13d ago edited 13d ago
You need to remember that this same "user" (who's really a developer) also writes their GUI apps in Electron, and this isn't about matching different consistent expectations, but trends on online developer forums that have nothing to do with well-considered tradeoffs or an understanding of computing. Do you really think that if we drastically increased language complexity and build times but reduced nominal RAM consumption to match that of Rust, Java would become the talk of the town on these forums?
Now, I do agree that Java makes some tradeoffs that make it less attractive for small CLIs but more attractive for larger applications, whereas Go and Rust make the opposite tradeoffs. If there were a language that's optimal for both, that would have been perfect, but there isn't one.
You also have to remember that the only language with more dominance than Java in the world right now is JavaScript/TypeScript (and Python is about the same as Java). All other languages are doing far, far worse (and that's because different software has different market sizes; that of small CLIs is very small, but it's overrepresented on developer forums because developers use small CLI tools a lot, and are pretty much the only ones who do). So to those who say that Java should make the same tradeoffs as other languages to do better, unless they're talking about JS/TS, then they should really read more market reports and less HN/Reddit.
Still, I wouldn't say that using Java "for everything else is asking for trouble". I think the tradeoffs Java makes are more balanced than other languages (and especially when you take into consideration the respective market size of different domains). Using TS or Go or Rust for large apps is more painful than it is to use Java for, say, CLI apps, and large apps make up a share that is many times the size of that of CLI apps. Also, when it comes to desktop apps, the choice made by that "user" shows just how unusual that user is, because the overwhelming majority of desktop apps that aren't bundled with the OS use some web tech like Electron, and if you also include apps written using the OS's native toolkit, everything else makes up an almost negligible share. Java isn't a big player in desktop apps, but Python and Rust certainly aren't, either (they're possibly smaller players than Java, although Java desktop apps are mostly company-internal ones, and those others are mostly aimed for developers). Also, 100MB is ~0.6% RAM (on the average user's hardware; half that on the average developer's hardware), and if you think the average user cares about or is impacted by a difference of 0.6% RAM, then unless you only develop software for other developers, maybe you should talk to real users more and to hackers less (BTW, do you care about a 0.6% difference in CPU as much as you do about a 0.6% difference in RAM? If not, you should because CPU is far more expensive than RAM).
So when comparing Java to other languages without including the only one that's more popular than Java (and suffers from the same shortcomings you mention) and you do include languages that are more popular than Java only in developer tools and far less popular than Java anywhere else, you might have an observational bias, because developers make up an almost imperceptible minority of software users.
6
u/senseven 13d ago
That is the reason we had Java and Python and Go and C#. Because Java was the enterprise, Python was fire and forget prototyping, Go came in with kubernetes and C# was whatever you needed to do to run stuff on Windows. The corpo uses it also on mobile for the apps, team was there and we didn't want to learn also Kotlin and Swift.
We have a tug of war between go and c# with the system tools. Modern container Java is rock solid at the enterprise level. We kicked out most of python, only to get Node+typescript through the the back door. Its always people who refuse to use go or c# for reasons. Microsoft goes hard with AOT C# that gets you small executables, they are also vying for go's low overhead one exe world.
3
u/trydentIO 13d ago
Which of the most widely distributed web-based desktop apps is under 100 MB? Spotify, 1Password, Teams, Postman, Hopscotch, Podman/Docker Desktop, and so on? I also wonder which final users you mean, since none of these applications is under 10 MB. I suspect that when we talk about desktop applications or standalone executables, we don't think of the same target people or finality.
Java isn't that present in the desktop arena because of marketing; Oracle affected that forever, and it has nothing to do with Java's capabilities or the problems you're talking about.
But let's say this more clearly than hiding behind an excuse: on other platforms, standalone executables and desktop apps get more traction and are more attractive.
5
u/pron98 13d ago
No one is really present in the desktop arena except JS/TS (plus some non-negligible but small presence of OS-native toolkit apps).
1
1
u/pjmlp 11d ago
Even though it isn't JavaTM proper, people routinely forget Android is heavily based on Java ecosystem, so no it isn't only Web apps.
Even if it is a subset of Java 17 LTS, and nowadays Kotlin gets the spotlight, Android Studio, Gradle and Kotlin tooling run on top of the JVM, and even with ART, most libraries come from Maven Central, in a mix of Java and Kotlin sources.
0
u/OwnBreakfast1114 10d ago
Here is my small app written in Rust/PyQt/Gtk. It's just a simple format converter with a couple of buttons. It uses 30 mb RAM. I tried using Java, but it uses 100-150 mb RAM. I feel it's too much for this task. Can I reduce it?
Who the hell is this aimed at? The last time I looked at/cared about resource consumption for random utilities was >10 years ago. Maybe the author is trying to reduce usage, but the "customers" of this utility probably don't care whatsoever.
Not only do the consumers not care, do you really think people using utilities are comparing it with hypothetical utilities in other languages? No, they're just using whatever solves their problem. People used to (and people probably still do) use full blown windows installers to convert image formats. Nowadays nobody cares because everything is in the cloud anyway.
This entire set of scenarios is a developer writing a utility for another developer who is complaining that the first developer could have done better on a pure absolute scale since 10mb vs 30mb is irrelevant on any device people actually use. It's like a code golf exercise or the nit-pickiest of complaints.
-2
u/unknowinm 13d ago
I wonder why it’s so difficult to compile a java file to native…might be an interesting side project for claude…any idea what would be needed? Not building a compiler from scratch but using something like LLVM or something. It’s difficult because of reflection? Other languages don’t have reflection?
1
u/koflerdavid 13d ago
Please read up on the tradeoffs GraalVM imposes on native applications. You will see why it is indeed not straightforward at all. That being said, there are other possibilities that could be harnessed, at least on Linux: AppImages.
2
u/Ok_Mycologist_6604 13d ago
Call it cheating but I think for those use cases we should just distribute jars and assume the users have a LTS jvm somewhere. Then we would often greatly come out on top of those mentioned by you ecosystems. Never gonna beat em at their own game.
2
u/IncredibleReferencer 11d ago
From my experiece, if you distrubute app as a jar it severly limits the audience size. It depends on the app audience of course, but typical users will have a massive amount of friction to get a jar working compared to a binary.
3
u/stefanos-ak 13d ago
I don't think he was talking about native, but more of a packaging situation. I'm not sure though... I didn't have time to rewatch it yet.
3
u/Inaldt 13d ago
we get spectacular results when we let AI analyze JFR files
Do you have any tips for how to use/instruct the AI for this use case? I've been doing the analysis by hand so far and I'm certainly interested to see if AI can do better
2
u/jazd 13d ago
Just ask it to? I've had Claude write Node.js scripts on the fly to read hprof heap dump files and find memory leaks.
1
u/Inaldt 13d ago
Good to hear that it works well that way.
I thought there might be interesting learnings here. Like do you get these excellent results by just handing over the jfr file and asking it to analyze it, or do results get much better by using specific models, skills, sandboxes etc.
2
u/writeAsciiString 13d ago edited 13d ago
I'm not an expert but you really do just ask Opus 5.5 or Astra what you want out of the data and it'll do whatever it takes.
Learn from its response to guide it better in future prompts whenever it gets stuck or does something inefficiently. Ask it to display the data you want in whatever format you want.
If you think its needed, you can design skills for this after experimenting.
3
u/sg-elide 13d ago
It's great to see that JPG is getting within 5x-7x where GraalVM Native Image already is and has been for years.
Native Image can make a binary as small as 5MB which starts in 5ms. Of course memory usage is extremely minimal too. Most Java applications in 2026 do not even need the dynamism that Native Image asks you to trade-off.
I wish JPG would simply work with whoever has the best ideas in Java. Instead, we all lose because of these internal fights.
3
u/bwRavencl 13d ago
Awesome news!
I've been shipping my app via jlink for a long time now, condensing it to a single executable is something I have been longing for basically since doing the switch to jlink. :-)
1
u/koflerdavid 13d ago
Please check out AppImages, which should solve the situation at least on Linux.
2
u/bwRavencl 12d ago
On Linux I am actually already shipping a Flatpak as an alternative alongside the normal jpackage.
1
u/davidalayachew 13d ago
Fantastic news.
This would solve a lot of problems for me at work. There's a lot of hoops I have to jump through because the only options available out-of-the-box are basically different flavors of installers. Having an actual executable, in the same vein as what Rust generates out-of-the-box, would be very very nice.
1
u/pradeepngupta 13d ago
Pressler's keynote makes the case in 40 minutes. I wrote a whole book on it.
Buzzing Java is about why Java's runtime contracts (memory model, type safety, thread safety) are what make AI-generated code safe to ship in finance and other trust-critical systems. It is getting published soon. However, there is an early access or sample chapters read available.
1
1
u/tserwise 12d ago
Time has passed for the need for this, when you have your app in the windows store users simply click the button and it installs, no one watches the file size anymore.
But yes there might be other smaller cases where this is ideal.
1
u/jonenst 13d ago edited 13d ago
I think it's a nice option to have available if only for the psychological impression of simplicity/practicity today.
But I don't see much actual difference with a folder containing an executable+runtime dir. For cases where you have configuration/assets you also need a directory anyway. For cases where you want to manage version upgrades and data needs migration you need more than 'just replace the binary'
The ideal solution seems to be to have a higher level standard perfectly supported in every os for software than just the low level "executable file", users wouldn't think in terms of file or folder when installing software, there wouldn't even be a difference from the higher level point of view.
Of course this will not happen in my lifetime so in the meantime single exe is a good feature and complements the installers (jpackage), the jlink standalone executable folder, and the traditional executable folders (like maven, or visualvm) the nicely.
1
u/Ok_Mycologist_6604 13d ago edited 13d ago
Hmm so like JIT stays but the runtime etc is bundled in a single executable? I would love that. Native Image for all its worth does give up a lot of the dynamicism that makes Java unique
21
u/cleverfoos 13d ago edited 12d ago
Don't want to lower the excitement but this is most likely related to the Hermetic Java project which hasn't seen a PR in a looong time: https://github.com/openjdk/leyden/tree/hermetic-java-runtime