13 ms·

Distribution of JVM Desktop Applications

133 points by nfrankel 6y ago

MaxBarraclough 6y ago
No mention of Graal. Does Graal Native Image work well with JavaFX? Seems appropriate to use ahead-of-time compilation for desktop applications.
- spijdar 6y ago
  What's the story with JavaFX nowadays? I'm not a Java dev, but from a user perspective it's a bit of a PITA since OpenJDK doesn't (?) package JavaFX with it (and neither does the latest oracle JRE/JDK?). It seems to be open source but the main program I'm thinking of, an old-school raytracer for minecraft Chunky [0] requires it be packaged with the JDK, hence the requirement for Java 8. Is this just laziness on the part of those devs to not package it up or is there something else going on? [0] https://github.com/chunky-dev/chunky https://github.com/chunky-dev/chunky
  - MaxBarraclough 6y ago
    JavaFX is no longer part of the core OpenJDK distribution, but it's not dead and gone, it's just maintained separately. There's no need to stay on Java 8 to use JavaFX, although I'm not qualified to speak on whether it would be a lot of effort to upgrade a JavaFX application to a newer Java.
    - fiddlerwoaroof 6y ago
      One issue is that I think Oracle forced package renames and, afaik, there’s no compatibility layer available for packages that expected the old Class Names. To my mind, this sort of defeats the purpose of the JVM’s universally unique symbol names.
      - MaxBarraclough 6y ago
        I don't think so. They were named javafx... both before and after, no? Doesn't sound like a real problem though. Renaming things is the easiest kind of change to accommodate.
        fiddlerwoaroof 6y ago
        I think I’m confusing it with the Java EE changes. However, renaming is only easy to accommodate if you have source access. The JVM’s model is portable binaries, so forcing renames breaks some of that model.
        MaxBarraclough 6y ago
        True, it would break binary compatibility.
        thu2111 6y ago
        JavaFX 15 API is compatible with that of JavaFX 8.
  - pvorb 6y ago
    Yes, this indeed looks like laziness of the developers to me. When the app was developed, JavaFX came pre-packaged with the JDK/JRE, so they still rely on it. Today, it should perhaps just be a regular dependency of your app and be part of your app. If I were to build a Java desktop application today, I would even bundle the entire JRE, since you cannot assume that it is installed on most desktops anymore.
  - vbezhenar 6y ago
    AFAIK you need to include JavaFX DLLs with your application and configure appropriate java.library.path. It's not laziness, JavaFX is not part of Java anymore, so you need to deploy it like any other native component.
- divs1210 6y ago
  It does. JavaFX + Graal Native is even used to make native mobiles AFAIK.
  - jariel 6y ago
    My understanding is that JavaFX is discontinued and so that 'it happens to still work with Graal' is just a bonus. Things change over time, so unless there is a focus on things actually working and integrating, this won't last. But please correct me if I'm wrong.
    - jariel 6y ago
      Oracle has in fact discontinued their support for JavaFX, and of course gave up on it long ago. It's apparently being supported by a tiny company 'Gluon' [1] so I'm wary to think that there will be any material progress comparable to a well supported platform. [1] https://gluonhq.com/products/javafx/ https://gluonhq.com/products/javafx/
      - thu2111 6y ago
        No they haven't. They still pay several developers to work on it and maintain it.
        jariel 6y ago
        Ok, meant to say they've signalled the fact they may not support in the future. It seems however they are not really backing it, more or less, doing the least to simply not let it fall over. Which is material.
foobiekr 6y ago
The very few Java desktop applications I've been inflicted with have been terrible. Memory hogs, terrible UI, etc. Maybe the time has simply passed?
- rstupek 6y ago
  As opposed to electron apps which are thin memory users and paragons of UI
  - pvorb 6y ago
    So much this. I understand that it's easiest to reuse your react skills to build your desktop application, but why does it have to consume so much memory? Is this something that's wrong with electron or rather the UI frameworks that run on it?
    - uncledave 6y ago
      Problem is it’s turtles all the way down. A lot of turtles. Each turtle is hungry.
    - exciteabletom 6y ago
      It is because every Electron app starts it's own Chromium instance.
- beders 6y ago
  Intellij is written in Swing. Yes on memory hog, no on terrible UI. It works quite well across platforms (I'm using the Windows and Mac version)
  - Kwpolska 6y ago
    IntelliJ uses a ton of custom widgets and styles, and nowadays even a custom JVM build to look the way it does. And on Linux, fonts in IntelliJ are hit-and-miss in my experience.
bambam24 6y ago
Tip of the decade , don’t use anything related to Java.
bullen 6y ago
I think the best way to do this is to just bundle a JRE in your application .zip?! You don't need an app to do that!
- pjmlp 6y ago
  JRE has been replaced by jlink on Java 9. Each application is supposed to create their customised runtime.
  - erik_seaberg 6y ago
    Debian and Fedora instructions for packaging Java apps do not recommend jlink. Modules only pay off for an embedded system with just one app. I've been out of the Windows world for years, but there appears to be an MSI story to require a JVM.
    - pjmlp 6y ago
      Good luck building a JRE yourself then, given that is not the way modern Java works.
      - erik_seaberg 6y ago
        Declaring a dependency on https://packages.debian.org/buster/default-jre https://packages.debian.org/buster/default-jre makes apt install the LTS release. A lot of comments here are actually advocating static linking, which is kind of a shock—I don’t see a good reason for it at all.
        pjmlp 6y ago
        Except it is up to Debian to keep that JRE running, as it is no longer part of default Java builds. All the JRE after Java 9 have to be maintained by the community, if they care to still use them. JRE don't work on the days of App Stores, even Google has finally grasped that ART cannot be part of the OS and has taken the steps to ship it out of band on Android 12.
ertucetin 6y ago
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... https://bugs.openjdk.java.net/browse/JDK-8259661 https://bugs.openjdk.java.net/browse/JDK-8259661
- elygre 6y ago
  The ticket is closed because the engineer found the bug report unconvincing, and needed more information. It is closed as "incomplete", which according to https://wiki.openjdk.java.net/display/HotSpot/Bug+Triage https://wiki.openjdk.java.net/display/HotSpot/Bug+Triage means > If the issue is incomplete, add a comment noting what is needed and close the bug as 'Resolved' - 'Incomplete'. This is our way of saying "need more information". This is the text from the actual bug report: > Looks like issue with provided demo app. [...] Please provide more complete example with command line used by jpackage, verbose output of jpackage and output of error message when resulting app is run from terminal.
pron 6y ago
> Java Web Start. This is the canonical way for desktop applications. 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 and the runtime, but users need not interact directly with the Java runtime anymore. Web Start, like Applets, was entirely predicated on the notion of the JRE. With the latter gone, the former is meaningless. Why was the JRE discontinued? 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. 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. > While it can in theory work with any application, it shines with modularized applications. Not just in theory. jlink is the 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 all Java applications should be distributed (jpackage internally uses jlink). (I work at Oracle on OpenJDK)
- chungy 6y ago
  > 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 Then what does the "java" command do exactly, if not run Java applications in some kind of runtime environment? > It is the responsibility of the vendor to deliver the application along with any dependency, including a Java runtime. Honestly, this appears to destroy a fundamental promise that Java made when it was first released: Write once, run anywhere. And not just in the present, but for future systems as well. Are we now expected to have vendors provide 30 different downloads tailored for every operating system and architecture combination possible? And if that application needs to be run in 10, 20 years when the packages that were made can no longer run directly? It seems like a fairly dismal state of affairs, to me. > 1. The software ecosystem now discourages system-wide third-party runtimes. On the desktop, the app store model rules Does "desktop" only include Mac OS? Neither on Linux nor Windows does the "app store model" rule. They exist, but are more like an obscure "you can also do it this way" method rather than the norm. > on the server, containers are popular -- both are much more friendly to an embedded runtime. Containers are indeed popular, and maybe an embedded-JRE makes sense. I personally stick with installing whatever JRE package comes with Debian, myself; run them the traditional way. It certainly clears up a lot of uncertainty about the security of whatever Java runtime is being used, when a distribution (eg, Debian, Fedora, RHEL, etc) with a reputable security team takes care of that issue for me. The Java runtime gets updated, my servers restart, instant security buff. Trusting this to software vendors is just insane. > although, admittedly, popular Java build tools currently lag in their support for jlink This seems to show that developers haven't bitten the Oracle dream of vendored JREs. The "old" way of launching Java applications, both desktop and server, works perfectly fine to the present day, and few seem to be willing to alter that.
TeaVMFan 6y ago
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! Intro article: https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/java-in-the-browser-wi... Migrating from Swing to TeaVM: https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaVm.html https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaV... A recent success story migrating from applets to TeaVM: https://news.ycombinator.com/item?id=26135892 https://news.ycombinator.com/item?id=26135892
- walkingolof 6y ago
  Scala.JS is an alternative if you write Scala, a compile target for the browser (or Node of course) that also can use most Typescript libraries via the Scalablytyped plugin
jorl17 6y ago
Many years ago, I wrote jar2app: https://github.com/Jorl17/jar2app https://github.com/Jorl17/jar2app 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". People often stumble upon the project and pose questions (same goes with some of my other projects like the barely-standing https://www.open-elevation.com/ https://www.open-elevation.com/ ), but I just don't have the energy and time to fix things, answer issues and all tat jazz 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 https://www.open-elevation.com/ https://www.open-elevation.com/ 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... 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). So, if anyone's out there, I'm sorry! I really just don't have the time, energy and in some cases the money...
c-smile 6y ago
1. Create minimal JVM and runtime with GUI primitives and compile it into .EXE 2. Create packager that concats class files (in JAR) of your application with that EXE. 3. Sign the exe. That's your monolithic application without external dependencies. Done. You can distribute your Java applications without any need for JRE, WebStart or anything like that. Did that once as J-SMILE (https://terrainformatica.com/org/j-smile/ https://terrainformatica.com/org/j-smile/) project. 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.
- watermelon59 6y ago
  That sounds far from trivial. Now in addition to your application you also have to maintain your minimal JVM to keep up with the latest developments in the mainstream ones.
  - Spivak 6y ago
    I mean it’s not that much more complicated than webpack. You don’t actually have to create your own minimal JVM. But “take the JVM source, remove a bunch of stuff, and then compile” is pretty pedestrian as far as carrying patches for your dependencies goes. There are shops that are running their own modified kernels in prod.
maxandersen 6y ago
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. (yes, I'm author of jbang.dev)
amake 6y ago
I can’t find a publishing date on TFA but > Launch4J is released under the BSD 3-Clause License but has not seen any release since 2017. Launch4j had a release just the other day.
torkus_1 6y ago
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. Here is my script to build a standalone linux binary: https://github.com/ogri-la/strongbox/blob/develop/build-linux-image.sh https://github.com/ogri-la/strongbox/blob/develop/build-linu... It comes out to about ~55MB typically: https://github.com/ogri-la/strongbox/releases https://github.com/ogri-la/strongbox/releases
msie 6y ago
For anyone wondering what a JRE has, which is more than a runtime: https://www.ibm.com/cloud/learn/jre https://www.ibm.com/cloud/learn/jre
EdwardDiego 6y ago
I'm looking forward to seeing what jpackage can provide. https://docs.oracle.com/en/java/javase/15/docs/specs/man/jpackage.html https://docs.oracle.com/en/java/javase/15/docs/specs/man/jpa... 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.
tealpod 6y ago
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).
unnouinceput 6y ago
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. 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.
- badsectoracula 6y ago
  Wouldn't Flash being ActiveX on IE make it the worst as it becomes the sum of both its own and ActiveX's badness? :-P (FWIW i think that complexity aside, ActiveX in general is a nice idea - but it wasn't designed for the web and Microsoft just shoved the closest equivalent they had to applets into IE because they were afraid of Java's compile-once-run-anywhere threatening their desktop dominance and ActiveX's reliance on x86 and Windows API would put a stop on that; but didn't put much care into it beyond that point)
mleonhard 6y ago
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. Can anyone share the reasons?
- hans_castorp 6y ago
  They did. The installers used to associate .jar with the java executable (at least on Windows) so a double click would start it. I don't know if they do this still.

133 points by nfrankel 6y ago

No mention of Graal. Does Graal Native Image work well with JavaFX? Seems appropriate to use ahead-of-time compilation for desktop applications.

spijdar 6y ago
What's the story with JavaFX nowadays? I'm not a Java dev, but from a user perspective it's a bit of a PITA since OpenJDK doesn't (?) package JavaFX with it (and neither does the latest oracle JRE/JDK?). It seems to be open source but the main program I'm thinking of, an old-school raytracer for minecraft Chunky [0] requires it be packaged with the JDK, hence the requirement for Java 8. Is this just laziness on the part of those devs to not package it up or is there something else going on? [0] https://github.com/chunky-dev/chunky https://github.com/chunky-dev/chunky
- MaxBarraclough 6y ago
  JavaFX is no longer part of the core OpenJDK distribution, but it's not dead and gone, it's just maintained separately. There's no need to stay on Java 8 to use JavaFX, although I'm not qualified to speak on whether it would be a lot of effort to upgrade a JavaFX application to a newer Java.
  - fiddlerwoaroof 6y ago
    One issue is that I think Oracle forced package renames and, afaik, there’s no compatibility layer available for packages that expected the old Class Names. To my mind, this sort of defeats the purpose of the JVM’s universally unique symbol names.
    - MaxBarraclough 6y ago
      I don't think so. They were named javafx... both before and after, no? Doesn't sound like a real problem though. Renaming things is the easiest kind of change to accommodate.
      - fiddlerwoaroof 6y ago
        I think I’m confusing it with the Java EE changes. However, renaming is only easy to accommodate if you have source access. The JVM’s model is portable binaries, so forcing renames breaks some of that model.
        MaxBarraclough 6y ago
        True, it would break binary compatibility.
      - thu2111 6y ago
        JavaFX 15 API is compatible with that of JavaFX 8.
- pvorb 6y ago
  Yes, this indeed looks like laziness of the developers to me. When the app was developed, JavaFX came pre-packaged with the JDK/JRE, so they still rely on it. Today, it should perhaps just be a regular dependency of your app and be part of your app. If I were to build a Java desktop application today, I would even bundle the entire JRE, since you cannot assume that it is installed on most desktops anymore.
- vbezhenar 6y ago
  AFAIK you need to include JavaFX DLLs with your application and configure appropriate java.library.path. It's not laziness, JavaFX is not part of Java anymore, so you need to deploy it like any other native component.
divs1210 6y ago
It does. JavaFX + Graal Native is even used to make native mobiles AFAIK.
- jariel 6y ago
  My understanding is that JavaFX is discontinued and so that 'it happens to still work with Graal' is just a bonus. Things change over time, so unless there is a focus on things actually working and integrating, this won't last. But please correct me if I'm wrong.
  - jariel 6y ago
    Oracle has in fact discontinued their support for JavaFX, and of course gave up on it long ago. It's apparently being supported by a tiny company 'Gluon' [1] so I'm wary to think that there will be any material progress comparable to a well supported platform. [1] https://gluonhq.com/products/javafx/ https://gluonhq.com/products/javafx/
    - thu2111 6y ago
      No they haven't. They still pay several developers to work on it and maintain it.
      - jariel 6y ago
        Ok, meant to say they've signalled the fact they may not support in the future. It seems however they are not really backing it, more or less, doing the least to simply not let it fall over. Which is material.

foobiekr 6y ago

The very few Java desktop applications I've been inflicted with have been terrible. Memory hogs, terrible UI, etc. Maybe the time has simply passed?

rstupek 6y ago
As opposed to electron apps which are thin memory users and paragons of UI
- pvorb 6y ago
  So much this. I understand that it's easiest to reuse your react skills to build your desktop application, but why does it have to consume so much memory? Is this something that's wrong with electron or rather the UI frameworks that run on it?
  - uncledave 6y ago
    Problem is it’s turtles all the way down. A lot of turtles. Each turtle is hungry.
  - exciteabletom 6y ago
    It is because every Electron app starts it's own Chromium instance.
beders 6y ago
Intellij is written in Swing. Yes on memory hog, no on terrible UI. It works quite well across platforms (I'm using the Windows and Mac version)
- Kwpolska 6y ago
  IntelliJ uses a ton of custom widgets and styles, and nowadays even a custom JVM build to look the way it does. And on Linux, fonts in IntelliJ are hit-and-miss in my experience.

bambam24 6y ago

Tip of the decade , don’t use anything related to Java.

bullen 6y ago

I think the best way to do this is to just bundle a JRE in your application .zip?! You don't need an app to do that!

pjmlp 6y ago
JRE has been replaced by jlink on Java 9. Each application is supposed to create their customised runtime.
- erik_seaberg 6y ago
  Debian and Fedora instructions for packaging Java apps do not recommend jlink. Modules only pay off for an embedded system with just one app. I've been out of the Windows world for years, but there appears to be an MSI story to require a JVM.
  - pjmlp 6y ago
    Good luck building a JRE yourself then, given that is not the way modern Java works.
    - erik_seaberg 6y ago
      Declaring a dependency on https://packages.debian.org/buster/default-jre https://packages.debian.org/buster/default-jre makes apt install the LTS release. A lot of comments here are actually advocating static linking, which is kind of a shock—I don’t see a good reason for it at all.
      - pjmlp 6y ago
        Except it is up to Debian to keep that JRE running, as it is no longer part of default Java builds. All the JRE after Java 9 have to be maintained by the community, if they care to still use them. JRE don't work on the days of App Stores, even Google has finally grasped that ART cannot be part of the OS and has taken the steps to ship it out of band on Android 12.

ertucetin 6y ago

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... https://bugs.openjdk.java.net/browse/JDK-8259661 https://bugs.openjdk.java.net/browse/JDK-8259661

elygre 6y ago
The ticket is closed because the engineer found the bug report unconvincing, and needed more information. It is closed as "incomplete", which according to https://wiki.openjdk.java.net/display/HotSpot/Bug+Triage https://wiki.openjdk.java.net/display/HotSpot/Bug+Triage means > If the issue is incomplete, add a comment noting what is needed and close the bug as 'Resolved' - 'Incomplete'. This is our way of saying "need more information". This is the text from the actual bug report: > Looks like issue with provided demo app. [...] Please provide more complete example with command line used by jpackage, verbose output of jpackage and output of error message when resulting app is run from terminal.

pron 6y ago

> Java Web Start. This is the canonical way for desktop applications. 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 and the runtime, but users need not interact directly with the Java runtime anymore. Web Start, like Applets, was entirely predicated on the notion of the JRE. With the latter gone, the former is meaningless. Why was the JRE discontinued? 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. 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. > While it can in theory work with any application, it shines with modularized applications. Not just in theory. jlink is the 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 all Java applications should be distributed (jpackage internally uses jlink). (I work at Oracle on OpenJDK)

chungy 6y ago
> 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 Then what does the "java" command do exactly, if not run Java applications in some kind of runtime environment? > It is the responsibility of the vendor to deliver the application along with any dependency, including a Java runtime. Honestly, this appears to destroy a fundamental promise that Java made when it was first released: Write once, run anywhere. And not just in the present, but for future systems as well. Are we now expected to have vendors provide 30 different downloads tailored for every operating system and architecture combination possible? And if that application needs to be run in 10, 20 years when the packages that were made can no longer run directly? It seems like a fairly dismal state of affairs, to me. > 1. The software ecosystem now discourages system-wide third-party runtimes. On the desktop, the app store model rules Does "desktop" only include Mac OS? Neither on Linux nor Windows does the "app store model" rule. They exist, but are more like an obscure "you can also do it this way" method rather than the norm. > on the server, containers are popular -- both are much more friendly to an embedded runtime. Containers are indeed popular, and maybe an embedded-JRE makes sense. I personally stick with installing whatever JRE package comes with Debian, myself; run them the traditional way. It certainly clears up a lot of uncertainty about the security of whatever Java runtime is being used, when a distribution (eg, Debian, Fedora, RHEL, etc) with a reputable security team takes care of that issue for me. The Java runtime gets updated, my servers restart, instant security buff. Trusting this to software vendors is just insane. > although, admittedly, popular Java build tools currently lag in their support for jlink This seems to show that developers haven't bitten the Oracle dream of vendored JREs. The "old" way of launching Java applications, both desktop and server, works perfectly fine to the present day, and few seem to be willing to alter that.

TeaVMFan 6y ago

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! Intro article: https://blogs.oracle.com/javamagazine/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/java-in-the-browser-wi... Migrating from Swing to TeaVM: https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaVm.html https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaV... A recent success story migrating from applets to TeaVM: https://news.ycombinator.com/item?id=26135892 https://news.ycombinator.com/item?id=26135892

walkingolof 6y ago
Scala.JS is an alternative if you write Scala, a compile target for the browser (or Node of course) that also can use most Typescript libraries via the Scalablytyped plugin

jorl17 6y ago

Many years ago, I wrote jar2app: https://github.com/Jorl17/jar2app https://github.com/Jorl17/jar2app 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". People often stumble upon the project and pose questions (same goes with some of my other projects like the barely-standing https://www.open-elevation.com/ https://www.open-elevation.com/ ), but I just don't have the energy and time to fix things, answer issues and all tat jazz 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 https://www.open-elevation.com/ https://www.open-elevation.com/ 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... 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). So, if anyone's out there, I'm sorry! I really just don't have the time, energy and in some cases the money...

c-smile 6y ago

1. Create minimal JVM and runtime with GUI primitives and compile it into .EXE 2. Create packager that concats class files (in JAR) of your application with that EXE. 3. Sign the exe. That's your monolithic application without external dependencies. Done. You can distribute your Java applications without any need for JRE, WebStart or anything like that. Did that once as J-SMILE (https://terrainformatica.com/org/j-smile/ https://terrainformatica.com/org/j-smile/) project. 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.

watermelon59 6y ago
That sounds far from trivial. Now in addition to your application you also have to maintain your minimal JVM to keep up with the latest developments in the mainstream ones.
- Spivak 6y ago
  I mean it’s not that much more complicated than webpack. You don’t actually have to create your own minimal JVM. But “take the JVM source, remove a bunch of stuff, and then compile” is pretty pedestrian as far as carrying patches for your dependencies goes. There are shops that are running their own modified kernels in prod.

maxandersen 6y ago

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. (yes, I'm author of jbang.dev)

amake 6y ago

I can’t find a publishing date on TFA but > Launch4J is released under the BSD 3-Clause License but has not seen any release since 2017. Launch4j had a release just the other day.

torkus_1 6y ago

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. Here is my script to build a standalone linux binary: https://github.com/ogri-la/strongbox/blob/develop/build-linux-image.sh https://github.com/ogri-la/strongbox/blob/develop/build-linu... It comes out to about ~55MB typically: https://github.com/ogri-la/strongbox/releases https://github.com/ogri-la/strongbox/releases

msie 6y ago

For anyone wondering what a JRE has, which is more than a runtime: https://www.ibm.com/cloud/learn/jre https://www.ibm.com/cloud/learn/jre

EdwardDiego 6y ago

I'm looking forward to seeing what jpackage can provide. https://docs.oracle.com/en/java/javase/15/docs/specs/man/jpackage.html https://docs.oracle.com/en/java/javase/15/docs/specs/man/jpa... 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.

tealpod 6y ago

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

unnouinceput 6y ago

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. 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.

badsectoracula 6y ago
Wouldn't Flash being ActiveX on IE make it the worst as it becomes the sum of both its own and ActiveX's badness? :-P (FWIW i think that complexity aside, ActiveX in general is a nice idea - but it wasn't designed for the web and Microsoft just shoved the closest equivalent they had to applets into IE because they were afraid of Java's compile-once-run-anywhere threatening their desktop dominance and ActiveX's reliance on x86 and Windows API would put a stop on that; but didn't put much care into it beyond that point)

mleonhard 6y ago

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. Can anyone share the reasons?

hans_castorp 6y ago
They did. The installers used to associate .jar with the java executable (at least on Windows) so a double click would start it. I don't know if they do this still.