Native executable which "just works"

[Lou Hamers]

What are the best options today for turning a Java desktop application into a cross platform native executable?

Preferences / specifics - I'll just throw it all out here:

JavaFX / Java 17
Targeting Linux... and I guess Win/Mac too
No dependency on having a JRE installed (bundle a JRE or at least make it getting it "installed" hands-off), this is probably the biggest issue here
Single file executable preferred with nothing extracted or installed to disk if possible
Need to be able to pass simple startup parameters
Something that integrates with Gradle nicely would be a plus

Too much? Realistic without spending thousands on something commercial?

[Stephan van Hulst]

There's no such thing as a cross platform native executable.

Either it's cross platform, or it's native.

You can build your code into a separate executable per platform. Is that what you want?

[Tim Holloway]

The closest thing to a "universal executable" for Java would have been the JNLP feature, but I'm not even sure that JNLP could bootstrap in the necessary JVM. Java cannot run without a JVM. JNLP isn't as well-supported as it used to be either, which I find disappointing.

In olden times, an additional roadblock was that the end user had to not only download and install a JRE from Oracle/Sun, but also agree to license terms, which meant that bundling a JRE with your product wasn't an option. Nowadays there's OpenJDK and it is often pre-installed on many Linux distros and possibly MacOS as well. If not, it's trivial to add it as an option to OS package installers. Doing it on Windows may be more problematic, since Microsoft has no love for Java.

Speaking of universal executable, though, you can't even do a one-size-fits-all package for Linux. Red hat/Fedora uses RPMs, Debian/Ubuntu uses "debs", and their are other installers as well.

Of course, there are other options, such as creating a ready-to-run container, but I'm not sure that Windows or even MacOS can universally run them.

On the whole, though desktop software isn't always the best solution these days. It's a pain to get installed, a pain to maintain and keep up to date, a pain to ensure that data is protected and backed up. Which is one of the primary reasons why so many apps are web-based now.

[Lou Hamers]

Oh no, I didn't mean literally one universal EXECUTABLE - I was thinking of one TOOL which constructs 3 different native binaries for 3 OSes. Well okay, it doesn't need to be a singular tool either, that would just be nice.

I can see why it was misunderstood based on how I wrote it though. Haha, yeah that was pretty unclear, sorry.

Web Start definitely not what I'm looking for, so we can rule that one out. I'm already way too familiar with JNLP stuff and I know enough to rule it out - hopeless cause there. Thus the desire for a native solution.

For Linux I'm thinking something like an AppImage https://appimage.org which from what I've seen do pretty well universally. There's some other options too like Snaps too. Although I think I'd be okay with separate packages too, deb/rpm etc.

So far Launch4J seems to be a leading contender for this... but, any other options?

[Lou Hamers]

Tim Holloway wrote:
On the whole, though desktop software isn't always the best solution these days. It's a pain to get installed, a pain to maintain and keep up to date, a pain to ensure that data is protected and backed up. Which is one of the primary reasons why so many apps are web-based now.

Just to address this separately, oh boy that's a can of worms and a whole thread topic there! For the type of user and application I've got in mind, you really want some decent OS level integration and file-associations. Certainly nicer than having to sign in to a webpage, requiring a working Internet connection, cloud storage that may be insecure, losing the use of things like shortcut hotkeys due to being browser-jailed, etc. (Yeah that stuff can be addressed, but it's probably not seen very often for a reason, and it's extra work compared to getting it for free with JavaFX.) Installs are "a pain" for casual users and casual activities, which unfortunately is the obvious majority, but I'm not worried about catering to that at all here.

So yes, I'm targeting the other stubborn old mules who still prefer desktop applications and a real PC, and one of the niche use cases where desktop still tends to be preferred over web junk.

[Stephan van Hulst]

Have a look at jlink, which is included right in the JDK.

I believe OpenJFX even has a short guide on how you can build native images of your JavaFX application using jlink. If you are using Maven to build your application, you can even integrate the step to automatically create the images using the maven-jlink-plugin.

[Tim Holloway]

I'm not sure that AppImage scales up to the level of containing multiple apps (JVM plus java app) like that. On the other hand, containers have no problem there. Other than requiring a container hosting service such as Docker or Podman. Lots of people do containerized Spring Boot apps.

Launch4J apparently only wotks under Windows, and I'm not sure if AppImage runs on anything but Linux.

As far as universal package creation goes, over the years I've seen several tools that can construct packages for RPM, deb and even Solaris. The catch is that you have to run them on the same OS as the target because they invoke native package utilities. So for the most part, you can't build debs on Red Hat, for example.

Incidentally, Maven does have an RPM plugin that I've used many times with good effect. There are also Debian and MacOS Maven build plugins, although I'm not sure if they are as well supported. Didn't see anything about a plugin for Windows Installer, but it was just a quick search. Again, these plugins will only run properly if the build is done on the same OS distro family that the package will be for, as they use native package builder apps.

[Lou Hamers]

Yeah I guess if there were anything better for this I'd have encountered it by now. Jlink I had intended on weaving into this if I can, but more of a nice to have.

Launch4j's website is a little confusing - it says it's "cross platform" but then it also says it's for "Windows executables". I suppose maybe that means its for "building across platforms" or something.

Yeah I'm pretty sure AppImage is just Linux too, but just running on Debian or Red Hat is a nice trick (which I believe it pulls off). It's a good question whether it'd work for this case, and "no" might be the safer guess. Something I'll have to look into for sure.

[Stephan van Hulst]

I just used javafx-maven-plugin and jpackage-maven-plugin to create a Windows executable that runs a JavaFX application. The result is a relatively small folder (less than 50MB) that contains not just the executable, but also the JavaFX modules and the Java runtime.

It's not a single self-contained executable, but it's the simplest thing I could integrate into the Maven build.
 <properties>    <mainClass>com.example.app.ExampleApplication</mainClass>    <module>com.example.app</module>    <vendor>Example Company</vendor>  </properties>  <build>    <plugins>      <plugin>        <groupId>org.openjfx</groupId>        <artifactId>javafx-maven-plugin</artifactId>        <version>0.0.8</version>        <executions>          <execution>            <phase>verify</phase>            <goals>              <goal>jlink</goal>            </goals>            <configuration>              <compress>2</compress>              <mainClass>${mainClass}</mainClass>              <noHeaderFiles>true</noHeaderFiles>              <noManPages>true</noManPages>              <stripDebug>true</stripDebug>              <stripJavaDebugAttributes>true</stripJavaDebugAttributes>            </configuration>          </execution>        </executions>      </plugin>      <plugin>        <groupId>com.github.akman</groupId>        <artifactId>jpackage-maven-plugin</artifactId>        <version>0.1.3</version>        <executions>          <execution>            <phase>verify</phase>            <goals>              <goal>jpackage</goal>            </goals>            <configuration>              <appversion>${project.version}</appversion>              <copyright>© ${project.inceptionYear} ${vendor}</copyright>              <description>${project.description}</description>              <module>${module}/${mainClass}</module>              <name>${project.build.finalName}</name>              <runtimeimage>${project.build.directory}/image</runtimeimage>              <type>IMAGE</type>              <vendor>${vendor}</vendor>            </configuration>          </execution>        </executions>      </plugin>    </plugins>  </build>