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 :)