alt Hacker NewsWhen I released my last Java project, I came out with a MacOS DMG, a Windows EXE installer, a Windows MSI installer, and a Fat Jar for Linux.
Now we have MacOS ARM, MacOS x86, Linux ARM/x86, Windows ARM/x86.
Even for a basic "cross platform" Java program (that bundles the JRE), that's 6 installs, which ostensibly need to be built on their respective platforms. Add on to that if you using something that includes a binary (like, say, SQLite, much less JavaFX which I work with).
The release burden is, well, frankly, daunting for a small project.
My honest thinking for my next project release is simply to tell folks to install the JDK, download the source code, and have them run:
./mvnw javafx:run.
That'll download all of the stuff it needs including the Maven runtime and all of the libraries, as appropriate, build the project, and run it. It's Fast Enough (maybe it's awful on a small RPi, I dunno).
When I get more than 5 downloads, folks can vote as to which installer to work on.
Creating the executables was quite the black hole. I didn't create one for Linux because I honestly didn't know what packaging scheme to use.
In theory, the CI infrastructure on GitHub will let you build on different platforms, yet another black hole of time to sink into.
So, yea, at least initially, I think the maven wrapper will be my "release model". SHOULD be pretty simple.
Replies
Distributing a single uberjar, whenever possible, is generally a good idea IMO. One major reason I like the JVM as a platform is that I don't need to mess with containers or native images. To reduce burden of deployment, native images are out of the question. Thus the choices are "force user to have Java runtime installed" or "force user to have container runtime installed". Double-clicking a JAR file (or running "java -jar ...") tends to be easier than debugging Mac / Windows quirks with Docker.
Presumably the major issue in distributing JavaFX applications (or most Java 9+ applications in general) is dealing with jlink. That leads to the problem in question: having to create N * M executable blobs, where N = # of operating systems and M = # of CPU architectures.
I faced similar problems some years ago, and frankly even if you use Electron the tools aren't that great. So I made a new tool (Conveyor) along with a company (Hydraulic):
Conveyor is free to use for open source projects and works how you'd hope it works: it's a signup/account-free downloadable CLI tool. You run a single command from your dev laptop (or a cheap Linux CI worker) and it builds/signs all the packages for every target OS and CPU architecture in one go, uploads them, and integrates the app with a native auto update engine. Sparkle on macOS, MSIX on Windows, an apt repository for Debian/Ubuntu users. It'll even make a download HTML page for you that detects the user's platform and gives a big green download button.
There's a bunch of sample apps showing how to integrate it into your {Electron,JavaFX,Compose for Desktop,native} app. "conveyor generate javafx my-sample-app" will spit out scaffolding that uses Gradle, and there's a Gradle plugin to import all the build info into Conveyor too. End result is you do:
./gradlew jar && conveyor make copied-site
> The release burden is, well, frankly, daunting for a small project.
With its large user base, I would have expected Java to have figured out all the details and offered users a single command-line tool that automatically builds the project into installers. I had adventures with relatable pain points when figuring out how to distribute Julia's GUI applications.
Another upcoming difficulty is transitioning to distributing applications that run in the sandbox. Windows has MSIX, Linux has Snap and Flatpack, and macOS has DMGs signed with entitlements. Each has its way of configuring and how it is expected to work, and debugging sandboxing issues is no fun.
I made an application bundler specifically for Julia's MSIX, Snap, and DMG applications, which allows the use of the underlying configuration files when configuring the sandbox via a simple recipe system. Unlikely one would change languages, but perhaps some inspiration can be taken from my project:
I create all those binaries automatically for my javafx project using GitHub actions, jlink, and jpackage, works well so far.
This burden is what prompted me to create JReleaser in the first place as I also wanted to release a JavaFX application without instructing people to clone a repository and build the app themselves.
Because JReleaser is a release tool and not a build tool you are free to build however it’s needed, collect all artifacts and release them. I do this for the Ikonli JavaFX browser: build the app with Gradle which bundles platform specific JARs, then release them with JReleaser.
https://github.com/kordamp/ikonli Shows how it can be done. Requires building with GH Actions in multiple platforms.