Vor wenigen Tagen wurde bekannt, dass Oracle die Abschaffung der Nashorn JavaScript Engine plant. Der Grund hierfür ist so banal wie einleuchtend: Es fehle an Ressourcen, die Nashorn Engine zu verwalten und auf dem aktuellsten Stand der Dinge zu halten. Das müssen die Nutzer nun beachten.
In freier Wildbahn werden Nashörner oft wegen ihrem kostbaren Horn gejagt. Weniger blutig und grausam ist hingegen Oracles Nashorn-Jagd: JEP 335 beinhaltet den Vorschlag, die Nashorn JavaScript Engine zunächst als deprecated zu markieren (also zum Abschuss freizugeben) und schließlich in einem künftigen Release des JDKs komplett auszulagern.
Der Grund hierfür ist der Mangel an interessierten und engagierten Entwicklern, die sich um die Aktualisierung und Verwaltung der Script Engine kümmern können. Das liegt nicht unbedingt daran, dass kein Interesse daran besteht, allerdings entwickle sich die Sprache JavaScript, so ist dem Vorschlag zur Entfernung zu entnehmen, einfach zu schnell, als dass man sich Seitens des Java-Anbieters damit in Zukunft befassen könne.
Drei JDK-Module im Visier
Obwohl das API javax.script nicht von der drohenden Deprecation betroffen ist, sind doch drei Module des JDKs auserkoren, mit der einem Todesurteil gleich kommenden @Deprecated(forRemoval=true)-Annotation gebrandmarkt zu werden:
jdk.scripting.nashorn: Dieses Modul enthält die Packagesjdk.nashorn.api-scripting&jdk.nashorn.api.treejdk.scripting.nashorn.shell: Dieses Modul enthält das ebenfalls zum Abschuss freigegebenejjs-Tool.jdk.dynalink: Dieses Modul enthält die Dynalink-Support-Bibliothek.
Wird JEP 335 angenommen, wird die Ausführung des jjs-Tools eine Warnung ausgeben (Warning: The jjs tool is planned tob e removed from a future JDK release). Für das endgültige Entfernen der Typen und Module wird ein weiteres JEP eröffnet, wenn es soweit ist.
GraalVM zur Rettung!
Wie so oft bei solchen Ankündigungen ist die Reaktion aus der Community gespalten. Die einen zucken nur müde lächelnd mit den Schultern und raten von der Nutzung von JavaScript im Allgemeinen sowieso ab:
On the other hand #javascript is so broken by design that it should be deprecated as a whole and replaced with some more robust technology like strongly-typed #typescript
— Julien Aubin (@julek42) 7. Juni 2018
Andere sind konstruktiver und geben zu bedenken, dass man auch stattdessen einfach GraalVM bzw. GraalJS nutzen kann. Dieses Projekt ist nach 7 Jahren Entwicklungszeit, wie Project Lead Thomas Wuerthinger auf dem Blog von Oracle ankündigt, gerade in Version 1.0 erschienen.
GraalVM, die universelle Virtual Machine, erlaubt es, JVM-basierte Sprachen wie Java, Scala, Groovy oder Kotlin, JavaScript (inkl. Node.js) und LLVM Bitcode (aus Programmen, die in C, C++ oder Rust geschrieben sind) laufen zu lassen. Auch für Ruby, R und Python gibt es bereits experimentelle Versionen. Der Clou: die GraalVM kann entweder eigenständig gestartet werden oder in Plattformen wie das OpenJDK eingebettet werden. Ein adäquater Ersatz also für die Nashorn JavaScript Engine, meinen viele.
Die Community ist gefragt
Ganz aufgeben muss man die Hoffnung auf einen Verbleib der Nashorn Engine allerdings nicht. Oracle gab an, dass man über die Entfernung der JavaScript Engine aus dem JDK durchaus noch einmal nachdenken könne, sofern sich eine Gruppe von renommierten und engagierten Entwicklern finde, die sich um die Weiterentwicklung und die Wartung von Nashorn bemühen würden.
PS: Die Nashorn JavaScript Engine ist keinesfalls der erste Versuch, JavaScript direkt in Java Code einzubetten: Nashorn ersetzte ab JDK 8 die Rhino Scripting Engine und stellte seinerzeit eine komplette Implementierung der Version 5.1 des ECMAScript-Standards dar.
Weitere Informationen zum möglichen Aus für die Nashorn JavaScript Engine gibt es im JEP 335 und dem zugehörigen Eintrag im JDK Bug System