Yeah it’s funny how “Java runs everywhere” was a huge selling point of the JVM. But now it’s not even included in macOS by default, so if you want somebody to use you Java/clojure CLI they have to install Java. And that will raise eyebrows and make people think “what is this, 2010??”

jpackage

It does all of this work for you and its a standard tool that dumps out a platform specific application bundle.

The only people living in 2010 are the ones that choose to live there with incredibly outdated takes on things they dont understand.

Bundling the JRE in the bundle typically results in something that is not redistributable with the default OpenJDK license: The Java ecosystem is heavily tilted towards the Apache license, but Hotspot is licensed under the GPL v2 only (no classpath exception). The Apache license and older GPL versions (before 3) are generally assumed to be incompatible.

Every modern openjdk build is licensed as GPLv2 + classpath exception. That exception includes hotspot, since it's part of the jvm. That exemption allows shipping the JVM with your app or linking to it. Otherwise a bunch of enterprise software couldn't exist.

This is not true.

Even Eclipse and Intellij ship openjdk based runtimes with their distributions and have even stricter GPL limits.

Has jpackage been updated to create things that are not installers and don't extract themselves into several files?

You're asking about a fundamentally different thing.

An app bundle (.app, .rpm, .deb, .msi/.exe etc.) are things jpackage can build for you and are a single shippable artifact for a user with a JRE included so they don't need to do that. It's designed to make it easy to ship Java applications around.

If you want a fully statically linked binary you're diving into graalvm and native-image: https://www.graalvm.org/latest/reference-manual/native-image.... This will give you what you want which is basically something you can wget and chmod +x.

I'm not asking about a fundamentally different thing. The success of other languages isn't because they produce installers. Have you tried native image for a non-trivial application? I've been using it since it came out; I was the first adopter of native-image for Quarkus on Windows. I even wrote the documentation for it at the time. It is not trivial to use, the compile times are extremely long, and the resources it requires are sometimes more than a developers machine can provide.

Every time I've tried to get native-image working with anything more than a basic Swing app it has been absolute hell.

> platform specific

Write once, run everywhere.

java -jar <jar-file>

Or use a graal to build a native-image and ship that around.

But that's not what people want. They want an .exe or a .app, or .rpm, or whatever. That's a container for holding that .jar and it is platform specific and there is no workaround to that problem.

graalvm native binaries?

Openjdk also dropped a lot of OS support, it basically just windows, Mac and Linux now. And AIX.

No more FreeBSD, Solaris, open Solaris (illumos smartos etc).

just because Oracle stopped distributing JDK's is not the same as not possible. Anyone can step up to do this.

https://github.com/psumbera/solaris-openjdk seem to work?

I never said it was impossible. I said they dropped support.

ok, but what practical implications does it has?

Pretty sure many other runtimes aren't exactly supported on all platforms by single vendor/projects?

java took a hit on this move by Java and Oracle...and the way they still provide a java executable that tells you to download from somewhere else is really annoying - but you do realize Apple removed python from Mac in 2024 and never distributed python3, right?

So will we see python stop being used?

No, because instead of sitting in corner and mope about it the ecosystem just kept working and filling in the gaps.

Java ecosystems done lot of that - but general public keep having the old changes stuck in their mind.

Lets change that :)

Yeah even js is better for CLI, just npm install it. The way its distributed also makes a huge difference.

jbang install does the same. Not enough for you?

I never came across it. I never used anything that installs with jbang, and I bet Im not alone.

Most devs have npm installed always, I don't like it but its effective at delivering software to my development environment.

yes, so now you know it exist - give it a try :)

and yes, works on npm, uvx, etc. too.

`npx @jbangdev/jbang`

Non-trivial, doesn’t work with standard build tooling, and unless something has changed it produces installers that extract into several different files. You don’t just get a standalone statically linked binary that you can hand off.

> Java will never become a player in CLI tooling until build packaging becomes first class.

Python packaging has always been painful and it’s a popular option for CLI regardless.

I don’t think there only rational explanations, technology choices are a lot about culture and dogmas too.

I think the python counterexample speaks a lot. A lot of languages "hide" their footprint in /usr/local or in a venv somewhere; out of sight, out of mind.

The JVM installs cleanly and is self contained, but any artifacts, by default, are not shared system wide as this _always_ have been seen as a security risk. The hot term for it today is "supply chain attack".

Instead, most Java programs tow their dependencies, giving it a bloated feel because its all just there, present in front of you, stored and running as your own user.

I know Python has been big in the space for longer than uv's existence, but uv (https://docs.astral.sh/uv/) has made Python packaging dead simple to me

I don't think uv makes distribution simple? Unless I've missed something, it doesn't do anything out of the box to help you produce a standalone artifact - it builds wheels but those are only useful for a user that already has python and pip, and don't do anything to deal with Python version drift etc.

uv can install a version of python of your choosing in addition to pulling the specific versions of libraries specified in your lockfile. it's extremely dummy-resistant.

Right, but that means the end user has to have (or install) uv, and then you ship them all your code, and then they can use uv to run that. That's a development workflow - and exactly what I meant when I said that uv didn't solve distribution in the way a language like Go or Rust does by producing a single binary.

uv does not solve all problems - but it for sure greatly improves chance of python tools working.

jbang is to java, what uv(x) is to python and what npm/npmx is to javascript.

Python packaging isn't really any more difficult than Rust, C# or Go if you use pyinstaller [1]

A single executable is always just one "pyinstaller --onefile --noconsole main.py" away.

[1] https://pyinstaller.org/en/stable/usage.html

I worked at a couple of startups that were mostly Java based and had several CLI tools. The focus was building "fat jars" then running them with "java -jar ...", or running scripts that did that. The Java VM was a system dependency and getting it baked into the binary just wasn't a practical concern.

I work at a startup that ships a Java cli to our clients. It is a giant pain in the butt. There are constant support requests from users that are using the wrong version of Java, too old or too new. Sometimes they have to wait weeks for authorization to even install the Java runtime. IT departments are extremely strict about installing Java.

I could see how that could be annoying. My experience was with internal apps whee we managed all the infrastructure. Some IT departments are often extremely strict about installing anything. Some won't even let you access a web site without it being proxied through something like ZScaler.

Yeah after we got bought our own IT department wouldn't let me use ngrok even though engineering was paying for licensing for it.

> IT departments are extremely strict about installing Java.

Understandably so, given that some Java runtimes (most notably, Oracle's) require a paid license for commercial use. Having users installing that can get the company in hot water.

Until 2021, now some do require a paid license for commercial use and some Java versions from Oracle can be used for free for commercial use.

Or do what the rest of the world does, use Eclipse Adoptium (the best JDK in my opinion) or the one from OpenJDK, Microsoft, etc.

You and the parent raising the specter of Oracle's Java licensing isn't applicable any more. It isn't 2009.

The point is, there are legal complexities which make it unsafe for an employee to go out on their own and download a JRE - sure, they might download Adoptium and be fine, but they also might download one of the ones which requires a commercial license. An IT department isn't going to be comfortable with that risk.

The article, which you may not have read, specifically calls out the use of JBang[1]for this purpose.

[1] https://www.jbang.dev/

I absolutely did read it when Max posted it to /r/java. Jbang doesn’t solve what you think it solves.

Actually, it probably does. Though I'm more of a fan of Java developing to a stage where it does what these 3rd party projects do and more.

Type the following prompt into any AI and feel free to argue your point with the AI: "what does jbang solve?"

what is it that you feel jbang does not solve in this?

> There is no way to get your jar + the vm into a binary.

My text editor, KeenWrite[1], offered binaries for Linux, macOS, and Windows. The Windows binary was axed due code signing costs and requiring third-party builds, rather than any technical issues with cross-platform packaging.

One way is to create self-extracting executable binaries using a tool such as warp[2]. I've built an installer script[3] (install.sh) to create platform-specific launchers. Running `time keenwrite.bin --version` on Linux shows 0.327s; after the first run, subsequent launches are quick.

[1]: https://keenwrite.com

[2]: https://github.com/kirbylink/warp

[3]: https://repo.autonoma.ca/?action=repo&repo=keenwrite.git&vie...

Java SHOULD never become a player in anything more until Oracle stops being such a threat. Oracle just wants to be a parasite on companies that actually build.

I like that Microsoft has a distribution of OpenJDK. Easy to trust if I'm on a windows system anyway. What's the risk?

https://www.microsoft.com/openjdk

Google is much more of a threat than Oracle.

How so? I've never had an employer or client be threatened with lawsuits from Google.

I gave up on Java when Oracle took over, because I thought that it was such a horrific move, but, to their credit, they haven't ruined it for everyone (yet)

They've kept it alive, allowed it to grow, and innovate, even let Green threads back in.

I'm not planning on going back to Java, but that's no longer because Oracle.

They have been better stewards of Java than Sun was IMO. I never would have expected it at the time, but it has turned out alright.

> Java on the other hand makes it impossible to get a single distributable.

Heh, I find this very amusing and ironic, seeing how Write Once Run Anywhere was a stated goal with Java, that failed miserably.

It was successful for a while. Java applets were once fairly common. But then Flash largely replaced them, and then Html5 killed them flat.

A very limited "anywhere", but yes.

For that use case, was it active content, was it shipping intermediate representation, was it a sandbox? To all three: yes, very poorly.

What's wrong with Maven and building fat JARs?

It's not dynamic linking, despite excellent support for very late binding in historic Java versions. (Newer versions require specific launcher configurations to use certain platform features, which breaks late loading of classes that use those features.)

>There is no way to get your jar + the vm into a binary.

GraalVM native image allows doing exactly that. Should be as easy as adding a single gradle plugin

isn't this exactly what modules and jlink do?

jar + vm into single binary feels like a solvable problem.

I haven't really had the burning need for app+jvm since I used graalvm and made jbang and its now trivial to run app + shared jvm for me - but I can see the utility for it.

Noted down the various pointers and existing attempt to explore in 2026 !

About build and publishing - this I feel is also solvable.

Especially if we stop trying to solve it for all possible mutations of gradle/maven builds and just make it work for jars...this is where jbang/jreleaser really simplifies more than I think many realize.

So in 2026 I'll definitely try get more recipes published on this and also see if we can make something like `jbang publish` "Just Work"

Yes we talked about this on Reddit. I don’t think it’s impossible it’s just work that needs to be done!

I really think that this aligns with the “paving the on ramp” type of stuff. Making the build tooling first class and simple will help adoption.

I’m not convinced that “single binary” really matters in practice. What actually matters is how easy it is to install, run, and update an application, and that depends entirely on the target user.

For end-user apps, this is basically solved: use jpackage to ship an installable app with a bundled, trimmed JRE. Better yet, distribute via the OS app store so updates are handled for you (on Linux, Flatpak is probably the right answer today).

For CLI tools, you’re already assuming a more technical audience. At that point you have two real options:

- ship everything bundled (Go/Rust static binaries, pyinstaller, jpackage)

- ship just the app and rely on a smart launcher/runtime manager (npx, bunx, uvx, jbang), and assume your technical audience can install that first

The real question isn’t "is it a single binary?", it’s "how do users install, run, and update it?". In practice, that’s already been solved by developer package managers like brew and scoop. All the Go and Rust CLIs on my machine are installed via brew, not manually downloaded from GitHub releases.

You also want CLIs on PATH or inside a dev environment (mise, direnv, etc.), so whether that executable is a true single binary or a symlink to a bundle is mostly irrelevant.

So the trade-off becomes, do you support `brew install foo-java-tool` with a bundled JRE, or do you ask users to `brew install jbang` and then `jbang install foo-tool`? Either way, the end result is the same, you run `foo-tool`.

Note, Claude Code for instance supports both options (curl | bash, brew cask, and npm -i), isn't a single binary, and that still hasn't stopped it from being the most popular CLI tool released this/last year.

There’s definitely room for improvement in Java’s packaging story, I just think the focus shouldn’t be on "single binary" as the primary goal.