Suche
JEP 222

JShell, die Java 9 REPL – Was kann sie eigentlich?

Werner Keil

© Shutterstock.com/pattara puttiwong

Unter den wenigen wirklich neuen Features, die vor kurzem für Java 9 bestätigt wurden (neben Project Jigsaw’s Modularität), ist eine Java Shell, die die erste REPL-Funktion in Java einführt. Werner Keil, Mitglied des Java Executive Committee, schildert hier, wie Javas neue REPL ihren Anfang nahm und wofür sie gut ist.

Wie im OpenJDK JEP 222 vorgeschlagen, bietet die JShell eine REPL (Read-Eval-Print Loop), um Deklarationen, Anweisungen und Ausdrücke der Java-Sprache zu evaluieren, sowie ein API, das anderen Applikationen erlaubt, ihre Funktionalität einzusetzen. Diese Idee ist nicht gerade neu. BeanShell etwa gibt es nun seit über 15 Jahren, fast so lange wie Java selbst, ganz zu schweigen von den vielen Scripting-Sprachen auf Scala und Groovy, die bereits ähnliche Shells bieten.

BeanShell (genauso wie Groovy, nebenbei bemerkt) unternahm durch den JSR 274 im Rahmen des Java Community Process einen Versuch der Standardisierung. Dieser JSR produzierte aber kein wahrnehmbares Ergebnis, obwohl (oder gerade weil?) sich mit Sun und Google zwei namhafte Unternehmen an der Expertengruppe beteiligten. Während der JCP.next-Initiative wurde er dann für „ruhend“ erklärt.

Ein irritierendes Vorgehen

Ein neues Java-Feature wie dieses via JEP hinzuzufügen statt das „ruhende“ JSR wieder aufzuwecken (was jeder, inklusive Oracle, dem mittlerweile das vormalige Mitglieder der Expertengruppe Sun gehört, hätte machen können), sorgte für Erstaunen unter den JCP EC-Mitgliedern. Weil der JCP gerade seine ME und SE/EE-Teile in einen einzigen Body gemergt hatte, kam die Befürchtung auf, dass sich durch die Entwicklung von immer neuen Plattform-Features  nicht als JSRs, sondern JEPs unter dem OpenJDK  ein weiterer Riss zwischen ME/SE (JDK) und EE, wo sich zu der Zeit die meisten der übrig gebliebenen JSRs befanden, auftun würde.

Das von einem proprietären Vorgänger unter Java ME abgeleitete Device I/O war bereits als OpenJDK-Projekt entwickelt worden. Ohne einen JEP kann Oracle – so scheint es zumindest – derartige Projekte auch ohne vorherigen Antrag ratifizieren. Die Farce um den JSR 310, der weder ein nennenswertes Spezifikations-Dokument produziert hat, das für alle JSRs verbindlich wäre, noch eine richtige, mit anderen SE-Plattform-JSRs wie Collection vergleichbare API aufweist, macht eines nochmals deutlich: der JSR hätte zurückgezogen oder für „ruhend“ erklärt werden sollen, sobald der JEP gestartet war. So war er nur dazu gedacht, einen JDK-Part vom EC absegnen zu lassen, völlig ungeachtet des tatsächlichen Ergebnisses des JSR außerhalb des OpenJDK.

Jede Klasse hat ein Javadoc, das zählt also nicht. Aufgrund der starken Beteiligung von Oracle werden wir wohl mehr JEPs unter OpenJDK sehen. In jedem Fall ist es vielversprechender, für diese Teile des Java-Ökosystems einen transparenten Versuch in Richtung Opensource zu unternehmen, als weiter mit einer geschlossenen Umgebung arbeiten zu müssen. Selbst wenn Teile des JCP (und des EC) dadurch entrechtet und geschwächt werden, ist das besser als überhaupt keine offene Entwicklung.

Mögliche Verwendungen für JShell

Eine solche Shell in Java zu haben, ist sicher keine schlechte Idee. Unabhängig davon, dass sie unter Java SE entwickelt wurde, könnte eine Standardshell für zukünftige Versionen von Java EE sogar weitaus attraktiver sein als für Java SE. Welchen Stellenwert Java ME haben kann, wird sich dagegen noch herausstellen müssen – vorausgesetzt das Downscaling wie bei Device I/O ist überhaupt möglich. Auf jeden Fall sollten IoT-Geräte mit Java SE Embedded von der Entwicklung profitieren.

Zumindest auf Windows und .NET wird indessen Windows PowerShell von einer wachsenden Anzahl von Systemadministratoren und DevOps-Teams präferiert. Von seinem Play Framework wird es dabei für administrative Aufgaben genutzt, während Groovy für ähnliche Aufgaben vom Spring Framework oder zumindest als Teil von JBoss Admin Shell verwendet wird. Derweil ist das WebLogic Scripting Tool (WLST) aus Jython – einer Python-Shell auf der JVM – hervorgegangen und die Java EE-Referenzimplementierung GlassFish hat eine Admin-Shell namens asadmin. Sollte man in zukünftigen Versionen einfach eine einheitlichte Java-Shell anzapfen können, dürfte nicht nur das Leben von vielen javabasierten Projekten, sondern auch das der Produkte, Entwickler und Ops, die die besagten Projekte nutzen, erheblich einfacher werden.

Andere interessante Anwendungsgebiete sind Bereichsspezifische Erweiterungen. Groovy, Scala oder andere Shell-fähige Sprachen – sowohl innerhalb der JVM als auch außerhalb – sind bei geschäftlichen oder wissenschaftlichen Kalkulationen sehr gefragt. Legt man frühe Eindrücke von JShell zugrunde, könnten Meldungen wie „assigned to temorary variable $ of type in“ allerdings sehr irreführend sein (siehe Abbildung 1).

Abbildung 1

Abbildung 1

Insbesondere im Finanzbereich dürfte man an US-Dollar denken, wenn man „$“ liest. Ergo: es gibt noch Raum für Verbesserungen. Doch beinahe natürliche Sprachabfragen wie Google beantworten Fragen wie „wieviel ergibt 2 plus 2?“. Und die seinerzeit sehr nette NoSQL DB Q&A bot solche Features bereits zehn Jahre, bevor Java überhaupt damit begann, sein großes Potential zu zeigen. Anstatt lediglich simple Fragen wie „2+2“ zu stellen, können Nutzer, unterstüzt von einer Smart-Home-Lösung, nach der Temperatur in ihrem Wohnzimmer fragen. Oder, unter Verwendung des JSRs 354, der kürzlich fertig gestellten Money API, nach der Wechselquote von Dollar in Schweizer Franken oder ähnlichem. An dieser Stelle wäre es verwirrend, würden temporäre Variablen „$“ auswerfen. Aber vielleicht findet das JDK-Team hinter JShell einen Weg, andere Ausdrücke zu benutzen.

Frink, benannt nach dem etwas abgedrehten Wissenschaftler aus den Simpsons, ist ein anderes wunderbares Beispiel für eine Java-getriebene REPL bzw. für eine Ausdruckssprache für wissenschaftliche oder arithmetische Herausforderungen. Es beantwortet die unterschiedlichsten Fragen, angefangen bei Zeit und Datum über Zeitzonenwechsel (wofür java.time aka JSR 310 sicherlich auch genutzt werden könnte) oder Währungsumrechnungen, wie diese:

"600 baht -> USD"

Frink stellt noch viele weitere mathematische und physikalische Formeln zur Verfügung, inklusive einer Funktion zur Umrechnung von Einheiten. Mit JSR 363, dem bald verfügbaren Java Units of Measurement Standard, wird das in ähnlicher Weise ermöglicht. Mit Groovy hat dessen Mitgründer Guillaume Laforge schon vor einer Weile ein DSL/REPL für Messeinheiten dokumentiert, der den JSR 275 verwendet. Die Lösung wurde in der medizinischen Forschung für Behandlungsmöglichkeiten von Malaria eingesetzt. Da sie in Java geschrieben ist, könnte man Sprache und System von Frink unter Java 9 selbstverständlich auch via JShell offenlegen!

Aufmacherbild: Alphabet from coffee beans von Shutterstock / Urheberrecht: pattara puttiwong

Verwandte Themen:

Geschrieben von
Werner Keil
Werner Keil
Werner Keil is an Agile Coach, Java EE and IoT/Embedded/Real Time expert. Helping Global 500 enterprises across industries and leading IT vendors, he has worked for over 25 years as Program Manager, Coach, SW architect and consultant for Finance, Mobile, Media, Tansport and Public sectors. Werner is an Eclipse and Apache Committer and JCP member in JSRs like 333 (JCR), 342 (Java EE 7), 354 (Money), 358/364 (JCP.next), Java ME 8, 362 (Portlet 3), 363 (Units, also Spec Lead), 365 (CDI 2), 375 (Java EE Security) and in the Executive Committee.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "JShell, die Java 9 REPL – Was kann sie eigentlich?"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Enttaeuscht
Gast

(Meine Meinung): Clickbait Überschrift für einen Artikel, der seinem Thema nicht im geringsten gerecht wird. Oder habe ich den Text übersehen, in dem erklärt wird, was JShell kann?