Interview mit Hendrik Ebbers über die Zukunft von Java Web Start und das OpenWebStart-Projekt

Java Web Start ist tot – es lebe OpenWebStart!

Hartmut Schlosser

Hendrik Ebbers

Mittels „Java Web Start“ lassen sich Java-Anwendungen über das Internet übertragen und ohne Browser starten. Allerdings hat Oracle den Support für Java Web Start abgekündigt und die Technologie seit Java 11 aus den offiziellen Java-Distributionen entfernt. Das Ende von Java Web Start? Nein, sagt Hendrik Ebbers (Karakun), der mit dem Projekt OpenWebStart eine Alternative ins Rennen schickt. Wir haben uns mit ihm über Zielsetzung, Status Quo und Zukunft von (Open)WebStart unterhalten.

„Java Web Start is dead“

JAXenter: Hallo Hendrik! Ihr habt vor Kurzem eine Alpha von OpenWebStart vorgestellt. Worum handelt es sich dabei?

Viele Firmen setzen noch immer auf WebStart.

Hendrik Ebbers: OpenWebStart ist eine Open-Source-Implementierung des WebStart- und JNLP-Standards (JSR-56). Dieser Standard wurde in Form von Oracle WebStart bis Java 10 vom Oracle JDK unterstützt. Da Oracle beginnend mit Java 11 allerdings kein WebStart Support mehr mit ihren JDK-Distributionen mitliefert und es von Oracle auch keine kostenfreien Updates mehr für Java 8 gibt, ist hier eine Lücke entstanden. Da noch immer viele Firmen auf WebStart setzen, haben wir uns dazu entschlossen, diese Lücke zu schließen. Hierbei arbeiten wir mit Red Hat und AdoptOpenJDK zusammen.

JAXenter: Die Headline des Ankündigungsposts beginnt mit „Java Web Start is dead.“ Das spielt darauf an, dass Oracle Java Web Start eigentlich aufs Abstellgleis gesetzt hat. Warum lassen wir es nicht da?

Hendrik Ebbers: Leider hat Oracle WebStart nicht nur aufs Abstellgleis gesetzt, sondern komplett aus Java entfernt. Die WebStart-Implementierung, die Oracle seit Java 1.4 ausgeliefert hat, war nie Teil des OpenJDK und somit auch nicht Open Source verfügbar. Ohne eine Open-Source-Alternative würden somit viele Firmen, die heute auf WebStart setzen, ein großes Problem bekommen.

Sicherlich ist WebStart nicht die Technologie der Zukunft, das ist auch uns und den bisherigen Nutzern von OpenWebStart bekannt. Allerdings sind viele Nutzer basierend auf der Informationspolitik von Oracle in ziemliche Bedrängnis geraten: Oracle hat 2016 während der Vorbereitung von Java 9 zu einer Migration nach WebStart geraten (Vergleiche https://blogs.oracle.com/java-platform-group/moving-to-a-plugin-free-web). Im Frühjahr 2018 wurde dann WebStart allerdings abgekündigt und war im Herbst 2018 mit dem Erscheinen von Java 11 bereits kurze Zeit später verschwunden. Vor allem große Unternehmen können interne IT-Prozesse (wie das Ausrollen von Clients) nicht innerhalb einer so kurzen Zeit umstellen. Durch das Fehlen von kostenlosen Security-Updates für Java 8 seitens Oracle bliebt diesen Nutzern nur die Wahl zwischen einem kostenpflichtigen kommerziellen Support für das Oracle JDK 8 oder der Nutzung von veralteten Version (letztes kostenloses Update von Java 8).

Lesen Sie auch: Java 11 ist da! Die neuen Features auf einen Blick

„Long live Java Web Start!“

JAXenter: Der zweite Teil der Headline lautet: „Long live Java Web Start!“ Wie groß ist denn noch das Interesse an einer Weiterführung?

Um das Projekt sinnvoll betreuen zu können, benötigen wir weitere Unterstützung von Firmen, die (Open)WebStart nutzen.

Hendrik Ebbers: Das Interesse ist auf jeden Fall groß. Aktuell erreichen uns viele Mails von Nutzern, die Beta-Releases von OpenWebStart bereits mit ihren Anwendungen testen. Teils gibt es hier noch Probleme, oft wurden wir auch schon gefragt, wann ein finales Release zu erwarten ist, da OpenWebStart für ihre Anwendungen sehr gut funktioniert. Da es sich bei OpenWebStart um eine Open-Source-Implementierung handelt, sind wir natürlich auf Sponsoring angewiesen. Hier gibt es auch bereits einige große Firmen wie etwa Daimler oder die LVM-Versicherung. Eine Liste kann man unter https://openwebstart.com/sponsors/ finden.

Für die Entwicklung der Beta-Versionen und verschiedener Kern-Features eines ersten Releases reicht dieser Support zwar aus. Um das Projekt aber in Zukunft auch sinnvoll betreuen zu können und alle wichtigen Funktionalitäten der JNLP-Spezifikation wirklich abbilden zu können, benötigen wir noch weitere Unterstützung von Firmen, die (Open)WebStart nutzen.

JAXenter: Wie kam es zu der Idee für das „OpenWebStart“-Projekt. Wer oder was war der Auslöser, wer steckt heute dahinter?

Hendrik Ebbers: Die Idee entstand Anfang letzten Jahres, als basierend auf der Ankündigung von Oracle WebStart verschiedene Firmen sich bei uns gemeldet haben. Im Frühjahr 2018 haben wir auf verschiedenen Konferenzen Talks zum Thema der Java Desktop Roadmap von Oracle gehalten und konnten da offenbar ein paar Teilnehmer „wachrütteln“. Initial kamen die Firmen auf uns (Karakun AG) zu, um eine Individuallösung als Replacement für WebStart zu entwickeln. Schnell haben wir gemerkt, dass wir hier die selben Arbeiten X mal machen würden. Dazu kommt, dass mit einer solchen Lösung jeder Kunde sein Projekt-Setup überarbeiten müsste, da ein kundenspezifisches Replacement aus Zeitgründen hier auf keinem Fall die JNLP-Spezifikation implementieren würde.

Da Red Hat vor einigen Jahren bereits mit IcedTeaWeb versucht hat, ein Open Source Replacement für WebStart zu entwickeln, haben wir mit Red Hat und IBM diskutiert, ob man nicht auf dieser Basis etwas aufsetzen könnte. IBM hat dann die AdoptOpenJDK Community als mögliche Basis eines solchen Projektes ins Spiel gebracht. Im Frühjahr dieses Jahres haben wir dann die Quellcodes von IcedTeaWeb nach GitHub migriert, ein Release für Java 8 erstellt und begonnen, den Support für Windows und MacOS auszubauen. Das aktuelle Repository von IcedTeaWeb kann man hier finden: https://github.com/AdoptOpenJDK/IcedTea-Web.

In IcedTeaWeb arbeiten wir aktuell daran, die JNLP-Spec abzubilden und deren Funktionen in einem möglichst großen Umfang zu unterstützen. Neben OpenWebStart, das IcedTeaWeb als Kern nutzt, wird IcedTeaWeb auch noch innerhalb von AdoptOpenJDK genutzt, um minimalen WebStart in den Java 8 Releases von AdoptOpenJDK bereit zu stellen. Diese sind gegenüber OpenWebStart allerdings beschränkt, da sie nur die aktuelle JVM zur Ausführung von JNLP-basierten Anwendungen nutzen können.

OpenWebStart – Features und Non-Features

JAXenter: OpenWebStart soll die wichtigsten Features von Java Web Start und dem JNLP-Standard enthalten. Welche sind das?

Uns ist eine gute native Integration in das Betriebssystem sowie der Support von möglichst vielen unterschiedlichen JVMs wichtig.

Hendrik Ebbers: Das wichtigste Feature ist sicherlich das automatische Downloaden / Updaten und Ausführen von JNLP-basierten Anwendungen. Aber auch hier bietet die Spezifikation viele Feinheiten, wie etwa den Lazy Download von Ressourcen einer Anwendung oder die Unterstützung von nativen Libraries. Eine Auflistung der Features mit Bezug zur Definition in der Spezifikation und dessen aktueller Entwicklungsstand kann man hier finden: https://openwebstart.com/feature-table/

Zu den Features, welche die JNLP-Spezifikation beschreibt und IcedTeaWeb bereits bietet, bringt OpenWebStart aber noch einiges mehr mit. Uns ist hier vor allem eine möglichst gute native Integration in das Betriebssystem sowie der Support von möglichst vielen unterschiedlichen JVMs (AdoptOpenJDK, Oracle, Amazon Coretto, etc.) wichtig. Daher veröffentlichen wir auch nicht einfach IcedTeaWeb, sondern nutzen es nur als Kern von OpenWebStart, um die JNLP Workflows abzubilden. Wir haben IcedTeaWeb in den letzten Monaten um verschiedene Schnittstellen erweitert, um mit OpenWebStart eine bessere User Experience bieten zu können. Bereits in der aktuellen Beta bietet OpenWebStart sowohl native Installer mit einem Wizard als auch ein Headless Installer, um das Tool z.B. automatisiert in einem Firmennetzwerk ausrollen zu können. Auch registriert sich OpenWebStart beim Betriebssystem, um JNLP-Dateien einfach per Doppelklick starten zu können.

Ein weiteres großes Feature, an dem wir aktuell arbeiten, ist der „JVM Manager“. Dieser findet automatisch installierte Java-Versionen auf dem lokalen System. Darüber hinaus kann der „JVM Manager“ Java Runtimes von dedizierten Servern herunterladen und diese intern verwalten, um JNLP Anwendungen immer mit der bestmöglichen Java-Version zu starten. Hierdurch müssen Firmen keine Angst mehr haben, dass ihre Anwendungen mit veralteten und nicht zugelassenen Runtimes gestartet werden. Der „JVM Manager“ kann auch so konfiguriert werden, dass er nur Runtimes von bestimmten Herstellern zulässt. Hat man als Firma z.B. einen Supportvertrag bei Red Hat und besitzt somit LTS Support für die Java-Distribution von Red Hat, so werden auch nur JVMs von Red Hat zur Ausführung von JNLP-Anwendungen genutzt.

Auch die OpenWebStart-spezifischen Features sollen als Open Source Code zur Verfügung stehen. Aktuell haben wir hier noch ein paar Issues mit kommerziellen Lizenzen von Tools zur Erstellung der nativen Installer. Sobald wir diese aber aus dem OpenWebStart Repository extrahiert haben, wird der komplette Code in den nächsten Wochen unter https://github.com/karakun/OpenWebStart zur Verfügung stehen.

JAXenter: Und welche Features von Java Web Start sind nicht mit dabei?

Hendrik Ebbers: Die fehlenden bzw. nicht geplanten Features kann man aktuell in zwei verschiedene Kategorien unterteilen. Einmal gibt es Features, welche aus Zeit- bzw. Budgetgründen aktuell nicht umgesetzt werden. Bei Befragungen von verschiedenen Firmen haben wir herausgefunden, dass diese Features in der Regel aber auch nicht wirklich bekannt sind bzw. nicht genutzt werden. Ein Beispiel hierfür sind die Definition von „j2ee-application-client-permissions“.

Dazu kommen einige Features, die Oracle WebStart bereitstellt, obwohl diese nicht Bestandteil der JNLP-Spezifikation sind. Ein Beispiel hierfür sind die sogenannten „Deployment Rule Sets“ (siehe https://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html). Neben diesen Features gibt es einige Punkte in der Spezifikation, die heute einfach keinen Sinn mehr ergeben oder mit aktuellen Java-Versionen überhaupt nicht umgesetzt werden können. Ein gutes Beispiel hierfür ist der Support von pack200. Dieser Komprimierungsalgorithmus macht sich Kenntnisse über das Java-Byte-Format von kompilierten Klassen zu Nutze, um Java-Anwendungen effektiv zu packen. Durch Änderungen im Byte-Code von Java-Anwendungen je nach genutzter Java-Version entstehen hier logischerweise Probleme. Daher wurde pack200 auch mittlerweile aus Java entfernt und kann daher auch nicht in OpenWebStart genutzt werden.

Java Web Start – mit Sicherheit?

JAXenter: Java in Webanwendungen – gerade hier gab es ja immer wieder Sicherheitsprobleme mit dem alten Java-Browser-Plug-in. Das war anscheinend nicht wirklich in den Griff zu kriegen und der Grund dafür, warum Java in Security-Statistiken immer weit vorn bei den höchsten Sicherheitsrisiken war. Wie geht Ihr mit diesem Problem um?

Ein Punkt, von dem OpenWebStart sich ganz klar abgrenzt, ist der Support von Applets.

Hendrik Ebbers: Ein Punkt, von dem OpenWebStart sich ganz klar abgrenzt, ist der Support von Applets. Wir unterstützen nur reine JNLP-Anwendungen, welche lokal auf dem System ausgeführt werden. Hierdurch ist auch keinerlei Browser-Plug-in mehr nötig. Dazu kommt, dass bereits IcedTeaWeb sich um Punkte wie die Signaturüberprüfung von JARs etc. kümmert.

Sicherlich gibt auch in diesem Bereich viele sicherheitskritische Punkte. Alle diese Punkte werden in der AdoptOpenJDK Community angegangen. Es gibt z.B. eine geschlossene Security-Gruppe im AdoptOpenJDK Team, die sich mit Security-Issues auseinandersetzt und diese mit hoher Priorität bearbeitet. Auch die Karakun AG stellt mittlerweile ein Mitglied dieser Gruppe und arbeit hier intern mit Red Hat und AdoptOpenJDK an schnellen und sicheren Lösungen von möglichen Security Issues.

Neben allen diesen Punkten planen wir, in OpenWebStart noch weitere Sicherheitsfeatures zu implementieren. So ist es z.B. angedacht, eine Server-Whitelist konfigurieren zu können und somit innerhalb einer Firma z.B. nur die Ausführung von internen JNLP-Anwendungen zu erlauben.

JAXenter: Wie soll es nun weiter gehen mit OpenWebStart? Welche Pläne habt Ihr?

Hendrik Ebbers: Aktuell liegt unser Hauptaugenmerk auf einem 1.0 Release. Dieses soll alle benötigten Features der OpenWebStart-Sponsoren beinhalten. Geplant ist, dass wir zur CodeOne einen Release Candidate bereitstellen und im vierten Quartal dann spätestens die 1.0-Version veröffentlichen.

Aktuell gehen wir davon aus, dass OpenWebStart als Projekt für einige Jahre Relevanz haben wird. Uns ist klar, dass WebStart keine Zukunftstechnologie ist. Allerdings wird es einige Zeit dauern, bis auch die letzten Firmen von WebStart zu einer anderen Technologie migriert haben. Solange hoffen wir, dass wir diesen Firmen mit OpenWebStart helfen können, eine geplante Migration durchzuführen und nicht unter Zeitdruck einen halbfertigen Workaround umsetzen zu müssen. Hierfür sind wir natürlich auch nach dem Release der 1.0-Version auf die Unterstützung von Firmen angewiesen. Da wir das ganze kostenlos zur Verfügung stellen, können wir eine Weiterentwicklung und Wartung nur durch kommerziellen Support gewährleisten. Dieser beinhaltet Vorteile wie etwa einen direkten Kontakt zum Support oder die höhere Priorisierung von Issues. Wer also heute WebStart nutzt und auch in den nächsten Monaten oder Jahren darauf angewiesen ist, kann gerne mit uns Kontakt (https://openwebstart.com) aufnehmen 🙂

Ein weiterer Punkt, den ich für die Zukunft als extrem wichtig ansehe, ist die Expertise, die wir als Community (Red Hat, Karakun, AdoptOpenJDK) mit diesem Projekt erlangen. Trotz der Abkündigung von Oracle WebStart gibt es auch heute noch keine wirklich zukunftssichere Technologie, auf die man ein WebStart-basiertes Projekt migrieren könnte. Aktuell muss man sich zwischen einem noch härteren Vendor-Lock-In oder halbfertigen bzw. bereits toten Open-Source-Lösungen entscheiden. Ich hoffe, dass wir mit den Knowhow, welches wir durch die Umsetzung von IcedTeaWeb und OpenWebStart erlangen, in Zukunft eine sinnvolle neue Technologie zur Verteilung, Wartung und Ausführung von Java-basierten Clientanwendungen bereitstellen können. Auch wenn heute sicherlich noch niemand sagen kann, wie diese genau auszusehen hat, ist es doch ziemlich klar, dass eine solche Technologie dringend benötigt wird.

JAXenter: Vielen Dank für dieses Interview!

Hendrik Ebbers is Co-Founder at 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’s blogging 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.

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. #java #eclipse #devops #machinelearning #seo. Zum Lächeln bringen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: