Interview mit David P. Caldwell

Die Nashorn JavaScript Engine vor dem Aus: „Rhino könnte dadurch wieder wichtiger werden“

Gabriela Motroc

David P. Caldwell

Ob es uns passt oder nicht, die Nashorn JavaScript Engine wird wohl auf kurz oder lang aus dem JDK verschwinden. In JDK 11 soll sie zunächst als deprecated, also „zum Abschuss freigegeben“, markiert werden. Diese Nachricht hat sich wie ein Lauffeuer in der Community verbreitet. Aber was ist die Folge dieser Ankündigung? Welche Alternativen gibt es? Sollte jemand das Projekt Nashorn übernehmen? Wir haben mit David P. Caldwell über diese Fragen gesprochen.

JAXenter: Wie denkst du über die Entscheidung, dass die Nashorn JavaScript Engine wohl aus dem JDK geworfen wird?

David P. Caldwell: Da das JDK 11 schon Ende des laufenden Jahres veröffentlicht werden wird, ist das Ganze natürlich ein wenig plötzlich. Aktuell bin ich mir nicht ganz sicher, wie breit diese Information bereits gestreut wurde, also ob die Community wirklich weiß, was da gerade passiert.

Möglicherweise sehen wir erst, wie viele Personen und Projekte davon tatsächlich betroffen sind, wenn sich der Status im JDK 11 dann ganz offensichtlich ändert. Ich könnte mir vorstellen, dass einige Leute zukünftig auf der Vorgängerversion (also Java 10) verbleiben, um Nashorn weiter nutzen zu können. Von einer solchen Engine auf eine neue zu migrieren, ist besonders in komplizierten Systemen nämlich nicht ganz einfach.

JAXenter: Wie intensiv nutzt du Nashorn? Kannst du uns ein paar Beispiele nennen?

David P. Caldwell: Ich nutze Nashorn und/oder Rhino ehrlich gesagt täglich für die gewöhnliche Anwendungsentwicklung. Ich arbeite an einem Open-Source-Projekt (SLIME), das von diesen Engines abhängig ist und auf diesem Projekt basieren wiederum einige Projekte meiner Kunden.

JAXenter: Die Diskussion zu Nashorn scheint noch lange nicht vorüber zu sein. Gibt es noch andere Leute, die deiner Meinung sind? Was denken sie über die Sache?

Ich könnte mir vorstellen, dass einige Leute zukünftig auf der Vorgängerversion (also Java 10) verbleiben, um Nashorn weiter nutzen zu können.

David P. Caldwell: Die Leute sind besorgt, was vor allem an daran liegt, dass dies ja mehr oder weniger aus dem Nichts heraus angekündigt wurde. Viele sprechen von der GraalVM als potentielle Alternative, verifizieren lässt sich das aktuell allerdings nicht, denn die GraalVM unterstützt mit der derzeit genutzten Version des jrunscript-Tools nicht einmal eine „Hello World“-Anwendung.

Davon abgesehen wird es ziemlich schwer, Anwendungen ohne einen richtigen Nashorn Compatibility Layer von einer eingebetteten JavaScript Engine auf eine andere zu portieren. Das gilt vor allem dann, wenn die Einbettung auf komplett andere Weise umgesetzt wurde. So wie es sich für mich darstellt, scheint diese bei der GraalVM nun tatsächlich deutlich anders realisiert worden zu sein (meine Produkte nutzen bspw. verschiedene Ebenen der Kommunikation zwischen Java und JavaScript) – ich habe sogar den Eindruck, dass es in vielen Fällen bei Nutzung der GraalVM einfacher wäre, Java in JavaScript einzubetten.

JAXenter: Welche Alternativen gibt es noch? Hast du schon etwas in der Richtung herausfinden oder gar testen können?

David P. Caldwell: Ich habe jahrelang Rhino genutzt und es ist sogar möglich, dass diese Geschichte um Nashorn nun dafür sorgt, Rhino wieder zu mehr Wichtigkeit zu verhelfen. Rhino wird als Open-Source-Projekt nach wie vor aktiv verwaltet und die Community ist daher schon seit Langem stark involviert. In mancher Hinsicht ist Rhino Nashorn sogar überlegen, da es eine höhere Startup-Geschwindigkeit an den Tag legt. Aber wichtiger ist die Community: Es kann sein, dass es sich schwierig gestalten wird, eine Community rund um Nashorn zu etablieren, da dieser Community-Aspekt historisch gesehen dort eben nicht vorhanden ist. Rein technisch sieht es auch so aus, als sei die Arbeit an Nashorn deutlich komplizierter. Auch wenn ich mir den Code selbst noch nicht angesehen habe, vereint Nashorn nun einmal sehr extravagante Technologien und Ansätze.

JAXenter: Ist die GraalVM denn nun eine gute Alternative oder nicht?

David P. Caldwell: Wir. Wissen. Es. Nicht. Für eine richtige Einschätzung oder Probe ist sie derzeit einfach noch nicht bereit. Wäre sie eine gute Alternative, dann ist es unverantwortlich, Nashorns drohendes Ende im Wissen anzukündigen, dass man die GraalVM als potentielle Alternative gar nicht in Betracht ziehen kann. Es ist also nur logisch, dass die Leute besorgt sind.

Die aktuellste Version der GraalVM (die ganz dubios als „Release Candidate“ bezeichnet wird) kann nicht einmal die jrunscript-Version von „Hello World“ ausführen. Ich habe also keine Ahnung, wie wir deren Nutzen verifizieren sollen.

JAXenter: Der Grund für das Fallenlassen der Nashorn Engine war, dass sie „schwierig zu verwalten“ sei. Glaubst du, jemand sollte Nashorn am Leben erhalten? Wie könnte das funktionieren und gibt es Leute, die sich dem annehmen würden?

David P. Caldwell: Ich bin schon der Meinung, dass man Nashorn retten sollte. Es gibt in jedem Fall Leute, deren Code auf den Besonderheiten der Nashorn-Einbettung oder privaten Nashorn APIs (ich gehöre dazu) basiert. Es war für uns absolut nicht zu erwarten, dass Nashorn einfach so verschwinden würde. Vor allem nicht, nachdem diese Engine als die Zukunft angepriesen wurde und seit Java 6 (also seit ZWÖLF JAHREN) eine JavaScript Engine fester Bestandteil der JVM war. Es muss nun eine Alternative geschaffen werden, denn es kann ja nicht sein, dass wir nun auf einem veralteten JDK festsitzen. Nashorn tut, was es tut, und das muss auch in Zukunft so bleiben!

Viele sprechen von der GraalVM als potentielle Alternative, verifizieren lässt sich das aktuell allerdings nicht.

Es könnte wie gesagt schwierig werden, eine Community rund um Nashorn zu etablieren, weil es da einfach noch keine Basis gibt. Es gibt aber ehemalige Nashorn-Entwickler, die nun nicht mehr bei Oracle arbeiten, und eine ganze Reihe von Nutzern, die Nashorn sehr intensiv einsetzen. Vielleicht könnte man diese Personen zusammenbringen und daraus eine Community heranzüchten, allerdings bedarf dies eines gewissen Engagements. Dies muss entweder von einer dieser Gruppen kommen oder von Oracle…oder von einer Organisation wie Apache.

JAXenter: Die offiziellen Gründe einmal beiseite gelassen – warum denkst du, hat Oracle sich dazu entschieden, Nashorn aufzugeben?

David P. Caldwell: Ich glaube Oracle, dass es für sie beinahe unmöglich ist, in Sachen JavaScript auf dem Laufenden zu bleiben. Insbesondere wegen der haarsträubenden Geschwindigkeit, mit der dort Innovationen vorangetrieben werden. Aber es wird schon auch ein wenig mit der GraalVM zu tun haben. Im GraalVM-Projekt hat man es hingegen geschafft, mit den Änderungen und Entwicklungen von JavaScript Schritt zu halten. So ist zu hoffen, dass sie die Vorteile realisiert, die man sich von Avatar.js bereits versprach. Node.js hat ebenfalls an Fahrt aufgenommen.

Mit dem richtigen Marketing hätte Nashorn tatsächlich zur würdigen Konkurrenz zum Node-Ökosystem werden können. Aber es hat eben an der Annahme durch die Entwickler und der generellen Bedeutung auf dem Markt gemangelt. Vielleicht könnte Oracle in Sachen JavaScript noch einmal vorankommen, wenn sie – ganz nach dem Motto „Wenn du sie nicht schlagen kannst, verbünde dich mit ihnen“ – ihre Kräfte in die Node-Kompatibilität stecken. Derzeit entwickelt sich alles in Richtung einer CLR-Strategie (Microsoft .NET), bei der es egal ist, in welcher Programmiersprache man Anwendungen schreibt. Für die JVM ist das der richtige Ansatz, denn die JVM-Sprachvarianten (bspw. Jython, JRuby, Rhino/Nashorn) haben bislang nie die Zuwendung bekommen, die sie verdienen. Vielversprechender sah es da in den Reihen der „neuen“ Sprachen wie Kotlin und Scala aus. Die GraalVM ist für die Sprachvarianten vielleicht eine neue Chance.

JAXenter: Welche Probleme werden auftreten, wenn Nashorn wirklich „abgeschossen“ wird?

David P. Caldwell: Einige Leute werden im Regen stehen, außer Oracle stellt einen kugelsicheren Nashorn Compatibility Layer zur Verfügung oder macht Nashorn sonstwie verfügbar. Es gibt aber noch einen Aspekt: Oracle und zuvor Sun haben es geschafft, die Rückwärtskompatibilität der Java-Plattform zu einer heiligen Pflicht zu erheben. Davon kann man, gerade wenn man das brutale JDK 1.0 Date API in Betracht zieht, halten was man mag. Unstrittig ist aber, dass dies Vertrauen geschaffen hat, das nun droht, verloren zu gehen.

JAXenter: Vielen Dank für das Interview!

David P. Caldwell is a senior consultant with over twenty years’ experience using Java and JavaScript to build systems for a wide variety of application domains, deployed on servers, desktops, the web, mobile devices, and telephone (IVR) systems, including the software that answers the phone when customers call the Apple Store in the United States, Canada, the UK, and Ireland. He took a three-year break from software development to work as a political consultant, primarily with LGBT rights groups in the United States. Currently, he is working with Shorelight Education building software to support students who want to come to the United States to pursue higher education, and managing his wife Justine Caldwell‘s campaign for State Representative. He lives in Rhode Island, USA, with Justine and their two children. E-mail: david@davidpcaldwell.com / Twitter: @dpcbiz
Geschrieben von
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Die Nashorn JavaScript Engine vor dem Aus: „Rhino könnte dadurch wieder wichtiger werden“"

avatar
400
  Subscribe  
Benachrichtige mich zu: