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

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

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

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