© Swill Klitch/Shutterstock.com
Eine ausführliche Einführung in die GraalVM – Teil 6

Multilinguale Programmierung


Manche Algorithmen sind in Java sehr umständlich zu formulieren. In JavaScript geht das vielleicht viel eleganter. Oder in C++. Mit GraalVM können wir das machen. Programme können aus mehreren Programmiersprachen bestehen. Wie gut funktioniert das in der Praxis?

Beginnen wir mit etwas völlig Verrücktem. Kennt ihr Ada? Das ist eine Programmiersprache aus den frühen 1980er Jahren. Außerhalb des US-Verteidigungsministeriums fand sie nur wenig Verbreitung, aber viel Aufmerksamkeit – und auch heute wird sie noch im TGV und dem Fly-by-Wire-System der Boeing 777 verwendet [1]. Mit Java hat Ada gar nichts zu tun – das sind komplett getrennte Welten.

Aber von solchen Kleinigkeiten lassen wir uns nicht abhalten. Für Ada gibt es einen LLVM Compiler, und mit LLVM kann GraalVM umgehen. Wir können also von jeder der zahlreichen Programmiersprachen, die GraalVM und Truffle unterstützen, unsere Ada-Programm aufrufen. Wie das in der Praxis aussieht, seht ihr in dem kurzen Video unter [2].

Hier wächst zusammen, was nie zusammengehörte (aber gut zusammenpasst)

Was uns verblüfft hat, ist, wie einfach das Ganze aussieht. Wahrscheinlich könntet ihr das sogar in einem effizienten Build-Prozess einsetzen. Im Grunde genommen besteht das Video ja nur aus zwei Zeilen, die ihr schnell in einem Shellskript automatisieren könnt:

llvm-gcc –S –g myAdaFile.ads –emit-llvm js --polyglot --jvm polyglot.js

Diese Einfachheit ist wichtig. Wir hatten euch im Rahmen dieser Serie erzählt, dass GraalVM eine bemerkenswert performante Implementierung der Programmiersprache R mitliefert und behauptet, das sei ein guter Grund für R-Programmierer, sich mit GraalVM zu beschäftigen. Nachdem wir den Artikel eingereicht hatten, haben wir gelernt, dass das nur die halbe Wahrheit ist. Selbstverständlich wollen auch R-Programmierer schnelle Programme schreiben. Ein häufiger Ausweg sind Bibliotheken, die in anderen Programmiersprachen geschrieben wurden. Die reine Geschwindigkeit der GraalVM ist daher sekundär.

Für GraalVM ist das eine enorme Herausforderung. Wenn es R unterstützen will, dann muss GraalVM auch einen Weg bieten, diese Bibliotheken zu verwenden. Traditionell greift man in diesem Fall auf Technologien wie JNI zurück. Das funktioniert, bindet euch aber sehr fest an euer Betriebssystem, ist oft schwierig zu handhaben und macht den Build-Prozess nicht einfacher. In vielen Fällen ist der LLVM-Bitcode eine elegante Lösung. Die Bibliothek wird kurzerhand in LLVM-Bitcode übersetzt und kann dann von GraalVM ausgeführt werden.

Wir kennen das Szenario nur aus Erzählungen (das aber aus erster Hand), ohne es selbst ausprobiert zu haben. Wir können euch daher nicht berichten, wie sich der LLVM-Interpreter von GraalVM im Vergleich zu den nativen Bibliotheken schlägt. Ihr könnt euch aber vorstellen, dass GraalVM in diesem Fall auf allen Ebenen punkten muss: Der LLVM-Bitcode muss schnell ausgeführt werden, der R-Quelltext muss schnell ausgeführt werden und der zusätzliche Kompilierungsschritt darf nicht allzu sehr stören.

Wofür brauche ich das?

Die meisten von euch sind vermutlich keine R-Programmierer – schließlich haltet ihr gerade das Java Magazin in Händen. Welchen Grund solltet ihr haben, euch mit polyglotter Entwicklung zu beschäftigen?

Dafür gibt es immer wieder Anlass. Oft gibt es eine bestimmte Bibliothek nur für eine Programmiersprache – aber nicht für die Programmiersprache, die ihr eigentlich verwenden wollt. Die Statistikbibliothek D3.js ist ein gutes Beispiel dafür. Wenn wir Autoren die Wahl haben, würden wir fast immer D3.js für die Darstellung von Statistiken und Grafiken verwenden. Dank GraalVM würden wir D3.js möglicherweise auch für Java-Programme ins Spiel bringen – auch wenn das nicht ganz so einfach ist, wie im eigentlichen Biotop von D3.js, dem Browser.

Datenbanktreiber sind ein anderes Beispiel. Sie sind manchmal nur für wenige Sprachen verfügbar. Vor ein paar Jahren mussten wir ein Node.js-Projekt abbrechen und nach Java migrieren, weil wir keinen passenden Datenbanktreiber für die OracleDB gefunden hatten. Mittlerweile scheint es solche Treiber zu geben [3], aber polyglotte Programmierung mit GraalVM wäre auch eine denkbare Lösung. Der Artikel von Michael Simons [4] behandelt ein ähnliches Szenario: den Zugriff auf die Neo4J-Datenbank mit Hilfe des Java-Treibers aus anderen Programmiersprachen heraus.

Manchmal ist es auch einfach so, dass bestimmte Dinge in einer anderen Programmiersprache einfacher gelöst werden können. Oder ihr wisst, dass eine Kollegin oder ein Kollege die Aufgabe schon gelöst hat, nur leider nicht in eurer...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang