Java Web Start is dead, long live Java Web Start!

JAXenter: You recently announced the Alpha version of OpenWebStart, can you tell us a bit about it?

Many companies still rely on WebStart.

Hendrik Ebbers: OpenWebStart is an open source implementation of the WebStart and JNLP standards (JSR-56). This standard was supported by the Oracle JDK in the form of Oracle WebStart until Java 10. However, since Oracle no longer provides WebStart support with their JDK distributions as of Java 11 and Oracle no longer provides free updates for Java 8, we noticed a gap here. Since many companies still rely on WebStart, we decided to close this gap. We’re working together with RedHat and AdoptOpenJDK.

Java Web Start is dead

JAXenter: The headline of the announcement post states, “Java Web Start is dead”. This alludes to the fact that Oracle has put Java Web Start on the shelf. Why don’t we leave it there?

Hendrik Ebbers: Unfortunately, Oracle not only shelved WebStart, but also completely removed it from Java. The WebStart implementation Oracle has delivered since Java 1.4 was never part of the OpenJDK and therefore not available as open source. Without an open source alternative, many companies that rely on WebStart today would face a big problem. For sure, WebStart is not the technology of the future, we and OpenWebStart’s users are well aware of that fact. However, many users have got into quite a bit of trouble due to Oracle’s information policy: Oracle advised users to migrate to WebStart in 2016 while they were preparing Java 9 (see https://blogs.oracle.com/java-platform-group/moving-to-a-plugin-free-web). In spring 2018, WebStart was discontinued and in autumn 2018 it disappeared with the release of Java 11. Large companies in particular cannot convert internal IT processes (such as rolling out clients) within such a short period of time. Due to the lack of free security updates for Java 8 from Oracle, these users only have the choice between commercial support for Oracle JDK 8 or the use of an outdated version (last free update of Java 8).

SEE ALSO: OpenJDK update: Early access Loom builds available

Long live Java Web Start!

JAXenter: The second part of the headline is “Long live Java Web Start!” How great is the interest in a continuation? International, or primarily in the DACH region?

In order to be able to support the project in the future we need further support from companies that use (Open)WebStart.

Hendrik Ebbers: There’s definitely a lot of interest. Currently, we get a lot of emails from users already testing the beta releases of OpenWebStart with their applications. Sometimes there are still issues, but we are often asked when a final release is to be expected because OpenWebStart works so well for their applications. Since OpenWebStart is an open source project, we are dependent on sponsoring; we already have some big companies like Daimler and LVM Versicherung on board. A full list can be found at https://openwebstart.com/sponsors/. For the development of the beta versions and various core features of a first release, this support is enough, but in order to be able to support the project in the future and really map all the important functionalities of the JNLP specification, we need further support from companies that use (Open)WebStart.

JAXenter: How did the idea for the “OpenWebStart” come about? Who or what was the trigger and who is behind it today?

Hendrik Ebbers: The idea was born at the beginning of last year when several companies contacted us based on the announcement of Oracle WebStart. In spring 2018, we held talks on the Oracle Java Desktop Roadmap at different conferences and obviously shook some participants awake. Initially companies approached us (Karakun AG) to develop an individual solution as a replacement for WebStart. We quickly noticed that we would do the same work over and over again. Additionally, with such a solution every customer would have to revise his project setup, since a customer-specific replacement would not implement the JNLP specification here due to time constraints.

Since Red Hat already tried to develop an open source replacement for WebStart with IcedTeaWeb a few years ago, we talked with Red Hat and IBM about whether it would be possible to build on their foundations. IBM then brought the AdoptOpenJDK community into play as a possible basis for such a project. In the spring of this year we migrated the source from IcedTeaWeb to GitHub, created a release for Java 8, and started to extend the support for Windows and MacOS. The current IcedTeaWeb repository can be found here: https://github.com/AdoptOpenJDK/IcedTea-Web. In IcedTeaWeb we are currently working on mapping the JNLP spec and supporting its functions as much as possible. Besides OpenWebStart, which uses IcedTeaWeb as its core, IcedTeaWeb is also used within AdoptOpenJDK to provide minimal WebStart in its Java 8 releases. However, these are limited compared to OpenWebStart because they can only use the current JVM to run JNLP-based applications.

OpenWebStart – Features and non-features

JAXenter: OpenWebStart should have the most important features of Java WebStart and the JNLP standard. What would you say they are?

It is especially important to us to have the best possible native integration into the operating system and to support as many different JVMs as possible.

Hendrik Ebbers: The most important feature is definitely the automatic downloading/updating and execution of JNLP-based applications. But here too the specification offers many subtleties, such as the lazy download of application resources or the support of native libraries. A list of the features related to the definition in the specification and their current state of development can be found here: https://openwebstart.com/feature-table/.

In addition to the features described in the JNLP specification and already on offer from IcedTeaWeb, OpenWebStart brings a lot more to the table. It is especially important to us to have the best possible native integration into the operating system and to support as many different JVMs (AdoptOpenJDK, Oracle, Amazon Coretto, etc.) as possible. As such, we won’t just publish IcedTeaWeb, but we’ll use it as the core of OpenWebStart to map the JNLP workflows. We have extended IcedTeaWeb with several interfaces in the last few months in order to offer a better user experience with OpenWebStart. The current OpenWebStart beta already offers native installers with a wizard as well as a headless installer to automatically roll out the tool across a company network. OpenWebStart is also registered with the operating system in order to start JNLP files simply by double clicking.

Another big feature we are currently working on is the “JVM Manger”. This will automatically find installed Java versions on the local system. In addition, the JVM Manager can download Java runtimes from dedicated servers and manage them internally to always run JNLP applications with the best possible Java version. This means that companies no longer have to fear that their applications will be started with outdated and unauthorized runtimes. The JVM Manager can also be configured to only allow runtimes from certain vendors. If, for example, a company has a support contract with Red Hat and therefore has LTS support for the Java distribution of Red Hat, only JVMs from Red Hat are used to run JNLP applications.

The OpenWebStart-specific features should also be available as open source code. Currently, we are experiencing some issues with the commercial licensing of tools used to create the native installers, but as soon as we have extracted them from the OpenWebStart repository the complete code will be made available at https://github.com/karakun/OpenWebStart.

JAXenter: And which Java WebStart features are not included?

Hendrik Ebbers: The missing or unplanned features can currently be divided into 2 different categories. First, there are features that are not currently implemented due to time or budget restrictions. By surveying different companies, we found out these features are usually not really known about or not used. One example of this is the definition of “j2ee-application-client-permissions”. In addition, there are some features that Oracle WebStart provides although they are not part of the JNLP specification. An example of this is the provision of so-called “deployment rule sets” (see https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html). Besides these features, there are some points in the specification that simply don’t make sense anymore or can’t be implemented at all with current Java versions. A good example of this is the support for pack200, a compression algorithm that uses knowledge of the Java byte format of compiled classes to effectively pack Java applications. Changes in the byte code of Java applications, depending on the Java version used, cause logical problems. Therefore, pack200 has been removed from Java and cannot be used in OpenWebStart.

Java Web Start with security?

JAXenter: Java in web applications – especially here there were always security problems with the old Java browser plug-in. Apparently, this was not really manageable and the reason why Java was always far ahead in security statistics with the highest security risks (e.g. https://www.av-test.org/en/news/adobe-java-make-windows-insecure/). How do you deal with this problem?

One point where OpenWebStart clearly sets itself apart is the support of applets.

Hendrik Ebbers: One point where OpenWebStart clearly sets itself apart is the support of applets. We only support pure JNLP applications running locally on the system. This means that no browser plug-in is required. In addition, IcedTeaWeb already takes care of points like the signature verification of JARs, etc.

Undoubtedly, there are many security-critical points in this area as well; all of these points are addressed in the AdoptOpenJDK community. For example, there is a closed security group in the AdoptOpenJDK team that deals with security issues and processes them with high priority. Karakun AG is now also a member of this group and works internally with Red Hat and AdoptOpenJDK on fast and secure solutions for possible security issues.

In addition to all these points, we plan to implement further security features in OpenWebStart. For example, it is planned to be able to configure a server whitelist and thus only allow the execution of internal JNLP applications within a company.

JAXenter: What’s next for OpenWebStart? What are your plans?

Hendrik Ebbers: Right now, our main focus is on a 1.0 release. This should contain all the features required by OpenWebStart’s sponsors. We plan to provide a release candidate for CodeOne and release version 1.0 in Q4 at the latest.

At the moment we’re working with the assumption that OpenWebStart will have relevance as a project for several years. We understand that WebStart is not next-generation technology, but it will take some time until the last companies have migrated from WebStart to something else. Until then, we hope OpenWebStart will help these companies to perform a planned migration and not have to implement a half-baked workaround under time pressure. For this, we are of course dependent on the support of sponsors – even after the release of version 1.0. Since everything is available free of charge, we can only guarantee further development and maintenance through commercial support. This of course includes advantages such as direct contact with support or higher prioritization of issues. So, if you use WebStart today and will depend on it for the next few months or years, please contact us (https://openwebstart.com)

Another point I consider to be extremely important for the future is the expertise we as a community (Red Hat, Karakun, AdoptOpenJDK) gain with this project. Despite the discontinuation of Oracle WebStart, there is still no future-proof technology to migrate a WebStart-based project to. Now you have to choose between an even harder vendor lock-in or a half-baked or dead open source solution. I hope that with the know-how we gain through the implementation of IcedTeaWeb and OpenWebStart, we will be able to provide meaningful new technology for the distribution, maintenance, and execution of Java-based client applications in the future. Although no one today can say exactly what it should look like, it is quite clear that such a technology is urgently needed.

Hendrik Ebbers is co-founder of Karakun AG and lives in Dortmund, Germany. He is the founder and leader of the Java User Group Dortmund and gives talks and presentations in User Groups and Conferences. He blogs about UI-related topics at www.guigarage.com (or on Twitter @hendrikEbbers) and his JavaFX book “Mastering JavaFX 8 Controls” was released in 2014 by Oracle press. Hendrik is a JavaOne Rockstar, JSR expert group member and Java Champion.

The post Java Web Start is dead, long live Java Web Start! appeared first on JAXenter.