> Java Web Start. This is the canonical way for desktop applications.<p>Not anymore. Java Web Start was removed because the very concept of a JRE, a system-wide runtime downloaded directly from Oracle and managed by the user or their IT department, no longer exists (despite some OpenJDK distributions offering something they call a JRE -- perhaps to maintain a sense of familiarity -- no one actually provides a JRE anymore, although I guess OpenWebStart is attempting to resurrect it). Like any other application, Java applications now only have two parties: the user and the application's vendor. It is the responsibility of the vendor to deliver the application along with any dependency, including a Java runtime. The vendor may choose to supply their own automatic update mechanism, for the application <i>and</i> the runtime, but users need not interact directly with the Java runtime anymore.<p>Web Start, like Applets, was entirely predicated on the notion of the JRE. With the latter gone, the former is meaningless.<p>Why was the JRE discontinued?<p>1. The software ecosystem now discourages system-wide third-party runtimes. On the desktop, the app store model rules; on the server, containers are popular -- both are much more friendly to an embedded runtime.<p>2. An embedded runtime with jlink gives the user a better experience by giving the software vendor full responsibility over their software and not requiring the user to deal with runtime components they don't, and need not, understand (although, admittedly, popular Java build tools currently lag in their support for jlink). In other words, the new way is better, but it does require getting used to.<p>> While it can in theory work with any application, it shines with modularized applications.<p>Not just in theory. jlink is <i>the</i> recommended practice for deploying any Java application, desktop or server, modular or not. While a modular application can help automate more steps of the packaging process (like not requiring running jdeps to find dependencies and automatically generating launcher scripts), jlink is not especially tied to modular applications. It is how <i>all</i> Java applications should be distributed (jpackage internally uses jlink).<p>(I work at Oracle on OpenJDK)
1. Create minimal JVM and runtime with GUI primitives and compile it into .EXE<p>2. Create packager that concats class files (in JAR) of your application with that EXE.<p>3. Sign the exe. That's your monolithic application without external dependencies.<p>Done. You can distribute your Java applications without any need for JRE, WebStart or anything like that.<p>Did that once as J-SMILE (<a href="https://terrainformatica.com/org/j-smile/" rel="nofollow">https://terrainformatica.com/org/j-smile/</a>) project.<p>That minimal JVM was of size 300 kb so nothing if to compare with the rest of .class files of your app. So Java executables can be in principle smaller than comparable Go's executables.
I use a Clojure, JavaFX, jlink and AppImage stack to build, bundle and distribute my app. I love it, it's a lot of fun.<p>Here is my script to build a standalone linux binary:
<a href="https://github.com/ogri-la/strongbox/blob/develop/build-linux-image.sh" rel="nofollow">https://github.com/ogri-la/strongbox/blob/develop/build-linu...</a><p>It comes out to about ~55MB typically:
<a href="https://github.com/ogri-la/strongbox/releases" rel="nofollow">https://github.com/ogri-la/strongbox/releases</a>
Many years ago, I wrote jar2app: <a href="https://github.com/Jorl17/jar2app" rel="nofollow">https://github.com/Jorl17/jar2app</a><p>At the time, I had a Minecraft jar on my hands, and I was tired of it not showing up in Spotlight's results because it was "just" a Jar. So I cobbled together this lazy script to get around that. I guess I got carried away writing the documentation when I published it, but it was never meant to be used "in production".<p>People often stumble upon the project and pose questions (same goes with some of my other projects like the barely-standing <a href="https://www.open-elevation.com/" rel="nofollow">https://www.open-elevation.com/</a> ), but I just don't have the energy and time to fix things, answer issues and all tat jazz<p>I feel _really_ bad for not helping people out, clearing their doubts, fixing their issues, and improving my "creations" that were thrown out into the world. It's just that from my perspective, these things I built are extremely simple, mostly weekend-projects, which were for my own use, and I just happened to put them out there to help out whoever needs them. I accept donations on <a href="https://www.open-elevation.com/" rel="nofollow">https://www.open-elevation.com/</a> to try to at least break-even on the cost of the hardware (I don't, not even close, but that's okay), but really I don't have time and energy to help out...<p>All this to say that I'm sure if I had put in just a tiny bit of effort throughout the years, even if just by looking at issues and pull requests created by others, I'm sure jar2app could be on this list (and _especially_ because of the work that others could have put into it, if I just provided them with feedback once in a while).<p>So, if anyone's out there, I'm sorry! I really just don't have the time, energy and in some cases the money...
The easiest way to distribute JVM applications on the desktop is the via the browser. TeaVM and Flavour make it easy to build rich browser apps in no time. You won't even miss Swing or JavaFX!<p>Intro article: <a href="https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm" rel="nofollow">https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...</a><p>Migrating from Swing to TeaVM: <a href="https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaVm.html" rel="nofollow">https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaV...</a><p>A recent success story migrating from applets to TeaVM: <a href="https://news.ycombinator.com/item?id=26135892" rel="nofollow">https://news.ycombinator.com/item?id=26135892</a>
There is a new problem with jpackage after JDK 14, when your app depends on native libs, you'll get UnsatisfiedLinkError. There is a ticket for that, but it seems that one core dev couldn't repro it and the ticket is closed now... <a href="https://bugs.openjdk.java.net/browse/JDK-8259661" rel="nofollow">https://bugs.openjdk.java.net/browse/JDK-8259661</a>
For anyone wondering what a JRE has, which is more than a runtime: <a href="https://www.ibm.com/cloud/learn/jre" rel="nofollow">https://www.ibm.com/cloud/learn/jre</a>
I'm looking forward to seeing what jpackage can provide.
<a href="https://docs.oracle.com/en/java/javase/15/docs/specs/man/jpackage.html" rel="nofollow">https://docs.oracle.com/en/java/javase/15/docs/specs/man/jpa...</a><p>Not sure about the platform specific builds, but I guess if you're going for proper integration with a platform, it's the easiest way.
I can’t find a publishing date on TFA but<p>> Launch4J is released under the BSD 3-Clause License but has not seen any release since 2017.<p>Launch4j had a release just the other day.
Other important and recent Java distrubution option is GraalVM Native Compilation. We are using it for a encryption app and Spring Boot app. Our final native version of GraalVM application is not only smaller in size but super fast. The only drawback with GraalVM is the time it takes to native compile is very high and heavy on CPU (I am sure this will be solved near future).
I've often wondered why Sun never made .JAR files an executable format like .sh, .bat, .tcl, .py, .doc, etc. It seems like a good way to reduce friction in binary distribution and get a lot more users of the language.<p>Can anyone share the reasons?
try out jbang.dev - will download and install JDK for your .jar, .java or even .jsh as long as its available via http, git or maven repository.<p>(yes, I'm author of jbang.dev)
The very few Java desktop applications I've been inflicted with have been terrible. Memory hogs, terrible UI, etc.<p>Maybe the time has simply passed?
Reading the article and seeing applets, my mind was like "hey, 90's tech, let's talk about ActiveX too". I mean, if we're talking about dead & malware ridden tech for web ActiveX is king, followed by Java applets and only in the 3rd place is Flash.<p>Don't get me wrong, current model of app stores and their "verified" apps is just as bad when it comes to malware, but hey, it is what it is.