How do I upgrade to jlink (JDK 9+) from Java Web Start (JDK 8) for an auto-updating application?

Question

Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:

1. Native code on Windows, Mac and Linux
2. Modularization of the code (although Proguard does this as well)
3. The use of new, supported technology.

The problem: I can't find the canonical Java solution to auto-update with jlink.

One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?

For the purposes of this question the following are out of scope:

• Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
• Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
• Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
• Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
• Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.

Parliament

It’s not only “slated for removal in JDK 11”, it has been removed already (as JDK 11 is out for a week now). As far as I can see, jlink allows you to create self contained runtime images for deployment, but it doesn’t provide the deployment itself, not to speak of auto-update features. That’s simply a service, Oracle doesn’t offer (anymore). – Longwinded

It may be that Oracle doesn't offer this service any more, but that doesn't prevent anyone/anything else from doing the same thing... – Parliament

Sure, it’s only a matter of time. I only addressed the question as-is (how to use jlink for that), which afaik has no satisfying answer, but since Stackoverflow is not a software recommendation service, broading the question would make it off-topic. So keep it as-is and hope for answers addressing it in a broader sense. I think, it’s a really interesting topic, but perhaps, it’s too early to expect solutions yet. – Longwinded

Maybe you want to give Getdown github.com/threerings/getdown a try. With Getdown you can actually even bundle and update the JRE you need with your application and don't rely on a client JRE being installed already. – Interleave

It looks like getdown requires a jre to run. This seems to be an induction failure, since we are trying to support users without jres – Parliament

Users without JREs? How do they run web start apps? With getdown you are able to ship the JRE together with your actual application. No need to have anything installed locally. You will however need to create bundles including a JRE for the initial deployment. – Interleave

There is an article at medium.com/oracledevs/… describing the process with a demo at github.com/udaychandra/auto-updater-demo – Itis

I am currently trying someting similar. For the initial installation the combination of a Custom Runtime Image and Inno Setup looks promising (targeting Windows), for updates I'll try getdown. – Gloria

Answer 1

In May 2019 commented to watch the OpenWebStart project.

Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.

The OpenWebStart Technical Details page states:

OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.

The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features¹ and their implementation status is provided in the feature table.

---

^{1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.}

---

^{Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.}

Silures

Answer 2

I had a similar problem in a past project. We needed to migrate from Webstart to another technology.

The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.

But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.

Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.

Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.

Jaenicke

What did you use to build an executable? jlink, and a set of machines, one per OS? Or something different? – Parliament

Answer 3

Do you use maven?

I've resolved my similar problem with maven (I need to update an EAR).

My main app (the ear package) has a pom.xml with listed the dependencies and repositories.

The dependencies have the <version> tag with a range (documentation) as in this example

<version>[1.0.0,)</version>

That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)

In the repository section I added my personal repository.

Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.

You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way

PRO

• This schema can be used in a lot of different projects.

CONTRO

• You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);

• You must write code in different jars and add them like dependencies in the main archive.

• You must change JAR version each time and publish on the repository (this could be a good practice)

Manganese