Kotlin kontra Java – Teil 2 – Multiplattform

Wer ein neues Projekt auf der Java Virtual Machine (JVM) aufsetzt, steht vor einer grundlegenden Entscheidung: Java oder Kotlin?

Möglicherweise besteht eine Präferenz aufgrund des Ökosystems – also der verfügbaren Tools, der Personen, die man um Hilfe bitten kann, und der nutzbaren Bibliotheken. Das war daher auch der Fokus von Teil 1 dieser Artikelserie. Oder es gibt eine Präferenz aufgrund der Möglichkeiten von Java oder Kotlin zur Modellierung der Geschäftslogik. Das ist der Fokus von Teil 3 dieser Artikelserie.

Was aber, wenn das Projekt nicht nur auf der JVM laufen soll? In diesem Teil wird untersucht, ob sich Java oder Kotlin auch für Endbenutzerplattformen jenseits des klassischen Servers eignen – von Mobilgeräten über den Desktop bis hin zu eigenständigen Web Frontends. Zur Einordnung der Relevanz hilft der weltweite Marktanteil der jeweiligen Betriebssysteme:

• Android (35 %)
• iOS (17 %)
• Windows (30 %)
• macOS/OS X (7 %)
• Linux (2 %)
• Web Frontend (fast überall 😊)

Für jede dieser Plattformen benötigt man:

1. Multiplattform-Laufzeit- und UI-Frameworks
2. Ausgereifte Multiplattform-Bibliotheken und -Frameworks

Plattformübergreifende Laufzeit- und UI-Frameworks

Java

Der Slogan von Java aus dem Jahr 1996 lautete „Write once, run anywhere“, und das trifft zu, solange die Zielplattform von der JVM unterstützt wird. Mobile Betriebssysteme wie iOS/Android und eigenständige Web Frontends haben dieses Versprechen jedoch etwas relativiert. Derzeit wird das OpenJDK als vorgefertigte Binärdateien bereitgestellt für:

• Linux / AArch64, Linux / x64
• macOS / AArch64, macOS / x64
• Windows / x64

Solaris wurde 2020 als veraltet eingestuft, Java ME hat seit 2018 keine neue Version mehr erhalten, Oracle selbst zertifiziert keine andere Plattform, und IBM AIX wird nur als Build-Plattform unterstützt.

Es gibt Möglichkeiten, Java auf Mobilgeräten oder in einem Webbrowser auszuführen, aber diese erfordern ein wenig – sagen wir mal – Kreativität.

Java auf Mobilgeräten

Der vielleicht einfachste Weg ist Java auf Android auszuführen. Obwohl Android technisch gesehen keine JVM verwendet (stattdessen nutzt es die Android Runtime [ART] und führt Dalvik Bytecode aus), kann Java-(Byte)Code zu Dalvik-Bytecode übersetzt und damit auf der ART ausgeführt werden.

Mit einer aktuellen Android Version kann man viele der Java 17-Kernbibliotheken nutzen. Viele fortgeschrittene Sprachfunktionen sind jedoch nicht verfügbar. Beispielsweise können Textblöcke (Java 15) und versiegelte Klassen (Java 17) verwendet werden, aber Records (Java 16) scheinen nicht unterstützt zu werden. Das Android Gradle Plugin (AGP) kann allerdings auch “de-sugar” durchführen (isCoreLibraryDesugaringEnabled) und moderne Java-Features im ART Bytecode abbilden. Es gibt hier aber keine mir bekannte Dokumentation, wie umfangreich der Feature-Support ist.

Dies macht die Programmierung von Java auf Android ziemlich knifflig. Dinge, die in der JVM funktionieren, funktionieren möglicherweise nicht in der ART. Dies betrifft natürlich auch Bibliotheken. Nutzt diese moderne Java Features, kann man sie eventuell auf Android nicht nutzen.

Um modernen Java-Code auf iOS zu nutzen, kann man Gluon verwenden. Es nutzt OpenJfx (eine GUI-Bibliothek und offizielles OpenJDK-Projekt) und GraalVM (mehr dazu weiter unten), um Java-Bytecode auf iOS und Android ausführbar zu machen. Das spezifische Tool, das sie verwenden, heißt Substrate. Im Hintergrund nutzt es Ahead-of-Time-Kompilierung (AOT) zu nativen Binärdateien anstelle einer JVM. Das bedeutet, dass man ein Programm erstellen kann, das die Java-Sprache, Java-Bibliotheken und das JavaFx-UI-Framework auf Mobilgeräten nutzt.

OpenJfx, das erstmals 2008 (damals JavaFx genannt) veröffentlicht wurde, wirkt allerdings etwas veraltet. Nicht wegen seines Aussehens (es lässt sich mit CSS stylen), sondern wegen der Developer Experience. Während neuere Bibliotheken (z. B. SwiftUI, Compose oder React) es ermöglichen, Anwendungen im Code hierarchisch zu „komponieren“, setzt JavaFx auf flache Komposition im Code oder hierarchische Komposition in Xml. Zudem ist sein Konzept des Property-Binding etwas umständlich. Dennoch ermöglicht dieses Framework die Erstellung von Desktop-Benutzeroberflächen für Linux, Mac und Windows sowie – mit Gluon – auch von mobilen Benutzeroberflächen. Gluon unterstützt JavaFx bis zur Version 26 (März 2026) und das JDK bis zur Version 26 (ebenfalls März 2026).

Es kann sein, dass es in Zukunft noch eine offizielle Möglichkeit geben wird Java direkt auf mobilen Endgeräten auszuführen. Das Ziel des OpenJDK-Mobile-Projekts ist es, das JDK auf beliebte mobile Plattformen wie iOS und Android zu portieren. Seit September 2025 gibt es eine funktionierende Pipeline, die eine HelloWorld-Anwendung auf iOS mit einer regulären JVM ausführt. Eine Beta-Version für mobile Endgeräte ist allerdings noch etwas entfernt.

Wie man sieht, gibt es also ein paar Möglichkeiten Java auf Mobilgeräten (Android und iOS) auszuführen. Derzeit ist Mobile jedoch keine offiziell unterstützte Plattform, sodass man auf Drittanbieter angewiesen ist. Für viele Anwendungen mag dies akzeptabel sein, bedeutet jedoch, dass der langfristige Support und die Stabilität des Ökosystems von der Zuverlässigkeit dieser Anbieter abhängen.

Java im Web Frontend

Die Java-Applet-API ist seit JDK 9 (2017) veraltet und wird in JDK 26 (März 2026) entfernt. Wenn man Java wirklich im Frontend ausführen will, gibt es grob drei Ansätze die möglich sind.

Man kann Drittanbieter wie CheerpJ oder WebSwing nutzen, die beide versprechen, Swing- oder JavaFx-Anwendungen im Browser auszuführen. Ersteres funktioniert durch die Ausführung von .jar-Dateien in einer Neuimplementierung von Java SE in JavaScript, mit einem Just-In-Time (JIT)-Compiler, der in Wasm läuft (einem portablen Binärcodeformat, das Browser nativ unterstützen). WebSwing dagegen funktioniert durch serverseitiges Rendern und Streaming der Benutzeroberfläche. Dies entspricht zwar nicht dem Ziel, „Java im Frontend auszuführen“, ist aber dennoch ein interessantes Tool. CheerpJ unterstützt JDK bis zur Version 11 (17 als Preview) und JavaFx zu gewissen Teilen. WebSwing unterstützt bis zu JDK 21.

Wenn man keine Benutzeroberfläche (Swing oder JavaFx) benötigt, kann man auch TeaVM verwenden, einen Compiler, der Bytecode in JavaScript+Wasm konvertiert. Da es mit Bytecode arbeitet, kann es auch Kotlin und Scala konvertieren. TeaVM unterstützt jedoch nur eine Teilmenge der Java-Standardbibliothek.

Das, was einer offiziellen Java-Unterstützung im Web am nächsten kommt, ist Graal, ein Projekt von Oracle. Es steht außerhalb des Java Community Process (JCP), der für die Weiterentwicklung von Java zuständig ist. Kurz gesagt handelt es sich um ein Projekt von Oracle, aber nicht um ein offizielles Java-Projekt; daher sollte man Graal eher wie das Projekt eines Drittanbieters sehen.

Vielleicht kennt man GraalVM, das Java Ahead-of-Time (AOT) zu einer nativen ausführbaren Datei für ein bestimmtes Betriebssystem und eine bestimmte Architektur kompilieren kann (eine Datei für macOS / AArch64, eine für macOS / x64 usw.). GraalVM verfügt jedoch auch über ein experimentelles Web-Image-Target. Dieses kann Java-Code in Wasm umwandeln, welches der Browser direkt ausführen kann. Neben dem Browser gibt es auch andere Laufzeitumgebungen, wie beispielsweise Wasmtime, aber Browser bieten bisher die umfassendste Wasm-Funktionsunterstützung.

Die Größe von einem Java-in-Wasm-Programm ist allerdings schwer vorherzusagen, weil sie stark davon abhängt, wie viel man von JVM und Standardbibliothek zusammen mit dem Programm ausliefern muss.

• Eine Bytecode-Datei HelloWorld.class ist etwa 500 Byte groß (erfordert eine JVM und stellt das absolute Größenminimum für den Vergleich dar)
• Eine Bytecode-Datei RandomNumber.class ist etwa 900 Byte groß
• Ein in Wasm konvertierter Zufallszahlengenerator in C ist etwa 500 Byte groß (siehe Wasm Wheel)
• Ein über TeaVM in Wasm konvertierter Java-Zufallszahlengenerator ist etwa 5 KB groß (siehe Wasm Wheel)

Was in diesem Vergleich fehlt, ist ein Beispiel mit Benutzeroberfläche. Hierauf hat das Web-Image-Target bisher keinen Fokus gelegt. Der Support von etwas wie OpenJfx fehlt.

Kurz gesagt: Die Konvertierung von Java in Wasm und die Ausführung im Browser ist möglich, aber man ist dabei entweder auf Tools von Drittanbietern oder auf experimentelle Tools von Oracle (kein offizielles Java-Projekt) angewiesen. Bei diesen ist der JavaFx Support allerdings eingeschränkt oder nicht vorhanden. Zudem ist eine Wasm-Laufzeitumgebung kein direkter Ersatz für die JVM. Sie weist (sehr) unterschiedliche Eigenschaften auf, auf die erst im nächsten Abschnitt eingegangen wird, wenn der Fokus auf plattformübergreifende Bibliotheken gelegt wird. Insgesamt ist der Support bei Kotlin deutlich umfangreicher.

Kotlin Multiplattform

Während Java von Anfang an auf die Ausführung innerhalb der JVM optimiert wurde, ist Kotlin eine Sprache, die für mehrere Plattformen kompiliert werden kann.

Kotlin kann offiziell für folgende Plattformen kompiliert werden. Die Jahreszahlen beziehen sich bis auf eine Ausnahme darauf, wann der Status auf “stabil” (stable) geändert wurde (siehe auch die Seite Stabilität von Kotlin-Komponenten). Zusammen bilden diese Plattformen Kotlin Multiplattform (KMP):

• die JVM (Kotlin/JVM) und Android seit Version 1.0 (Februar 2016) (auf Android ist Kotlin die von Google empfohlene Sprache seit 2019)
• für JavaScript seit Version 1.3 (Kotlin/Js, Okt. 2018) mit ES5 Standard, seit Kotlin 2.0.0-RC2 (2024) mit ES2015 Standard der auch Klassen und Arrow Functions bietet
• für iOS/macOS seit Version 1.9 (Kotlin/Native, Juli 2023)
• für Wasm (Beta) seit Version 2.2.20 (Kotlin/Wasm, Sep. 2025)

Für die JavaScript-Plattform sei noch angemerkt, dass die Umwandlung von Kotlin zu JavaScript zwar stabil ist, der Interop der Sprachen allerdings experimentell. Bis zur aktuellsten Version, Kotlin 2.4 (Juni 2026), muss man explizit dem experimentellen JsExport zustimmen (Opt-in). Erst nach dem Opt-in kann man Klassen und Methoden als @JsExport markieren, wodurch sie für JavaScript Code aufrufbar sind und sogar als EcmaScript Modul importierbar. Ohne Opt-In ist der Kotlin-Code in seiner eigenen kleinen Blase und kann JavaScript zwar aufrufen, jedoch nicht von diesem aufgerufen werden. Der Opt-in ist notwendig, weil sich noch ändern wird wie Kotlin Features in JavaScript und TypeScript beim Interop repräsentiert werden. Kotlin/Js war bis zum Release von Kotlin 2.0 wenig weiterentwickelt worden, weil es viele Einschränkungen beim 1.x Compiler gab. An einer Stabilisierung vom Interop wird seitdem wieder verstärkt gearbeitet.

Denn genau dieser Interop macht Kotlin aus. So kann beispielsweise Swift-Code Kotlin-Code aufrufen und Kotlin-Code Swift-Code. Dies ermöglicht eine schrittweise Migration von der Plattformsprache zu Kotlin oder umgekehrt, sowie die gemeinsame Nutzung von Code zwischen den Plattformen. Letzteres ist etwas, womit die norwegische Post großen Erfolg hatte.

KMP wird dabei noch interessanter, wenn man eine Benutzeroberfläche entwickeln will, die von mehreren Plattformen gemeinsam genutzt wird.

Compose Multiplattform

Während es bei KMP um die gemeinsame Nutzung von Logik geht, dreht sich bei Compose Multiplattform (CMP) alles um die gemeinsame Nutzung der Benutzeroberfläche.

Den Grundstein legte Google mit seiner deklarativen und Kotlin-basierten UI-DSL Jetpack Compose, die im Juli 2021 eingeführt wurde. Jetpack Compose und CMP nutzen gemeinsame APIs und einen gemeinsamen Kern, was ihnen perfekte Interoperabilität verleiht. Die Versionsnummern von Jetpack Compose und CMP sind daher auch synchron und die UI-Importe beginnen auf allen Plattformen, nicht nur auf Android, immer mit androidx.compose.*. Die Rendering-Bibliothek heißt Skia. Es handelt sich um dieselbe Bibliothek, die auch Google Chrome, ChromeOS, Android und Flutter verwenden. Zusammengenommen bedeutet dies, dass man übergreifende UIs entwickeln kann:

• auf Android und Desktop seit CMP-Version 1.0.0 (Dez. 2021)
• auf iOS/macOS seit CMP-Version 1.8.0 (Mai 2025)
• bald auch auf Web Frontend/Wasm, mit einer Beta-Version seit CMP Version 1.9.0 (Sep 2025)

Genau wie KMP ist auch CMP auf Interoperabilität ausgelegt. Man kann plattformnative Ansichten in CMP einbetten oder CMP in plattformnative Ansichten.

Fazit

Für Java bedeutet „Write once, run anywhere“, dass Code unter Linux, macOS oder Windows ausgeführt werden kann. Webbrowser oder mobile Plattformen wie Android oder iOS gehören nicht zu den offiziellen Zielplattformen. Wenn dies von Interesse ist, muss man auf Drittanbieter (mit Benutzeroberfläche) oder ein experimentelles Kompilierungsziel (ohne Benutzeroberfläche) zurückgreifen.

Kotlin erweitert das ursprüngliche „Write once, run anywhere“-Konzept über die Desktop-/Server-JVM hinaus. Mit Kotlin Multiplattform und Compose Multiplattform können dieselbe Sprache und weitgehend derselbe Code JVM, Android, iOS, Desktop, JavaScript und WebAssembly ansprechen und dabei weiterhin eng mit den nativen APIs und UI-Frameworks der jeweiligen Plattform zusammenarbeiten. In der Praxis macht dies Kotlin heute zu einer realistischeren Option für echte plattformübergreifende Entwicklung, insbesondere wenn man neben traditionellen JVM-Zielen auch Mobilgeräte und Web Frontends abdecken möchte.

Doch Support einer Plattform bedeutet nicht nur, dass die Sprache auf dieser ausgeführt werden kann. Es bedeutet auch, dass man ausreichend ausgereifte Bibliotheken auf dieser Plattform nutzen kann.

Ausgereifte plattformübergreifende Bibliotheken

Java

Java verfügt über rund 808.000 Pakete, darunter Spring (Boot), Jackson, Hibernate und JavaFx. Zum Vergleich: NuGet (.NET) hat 760.000 und npm (JavaScript) hat 5.000.000. Die Anzahl der Pakete ist natürlich nur ein grober Anhaltspunkt. Java-Pakete sind in der Regel umfangreicher, während npm viele Mikro-Pakete enthält.

Diese Java-Pakete können jedoch nur auf Plattformen mit einer JVM verwendet werden, und diese sind offiziell auf Linux/Mac/Windows beschränkt.

Java-Multiplattform

Nicht alle Java-Bibliotheken sind plattformübergreifend kompatibel. Wie bereits erwähnt, gibt es im Wesentlichen drei Möglichkeiten, Java auf anderen Plattformen auszuführen:

• Verwendung der Android-ART
• Kompilierung der gesamten Anwendung zu einem Native Image
• Kompilierung der gesamten Anwendung zu einem Wasm-Image

Alle drei Optionen wirken sich darauf aus, welche Bibliotheken man verwenden kann.

Java-Multiplattform Android

ART unterstützt nur eine Teilmenge des modernen Java, was Bibliotheken auf diese Teilmenge beschränkt. Es gibt hier leider keine offizielle Liste, welche Bibliotheken unterstützt werden und man muss immer ausprobieren, ob alles funktioniert.

Java-Multiplattform Mobile

Das native Image von GraalVM (das z. B. von Gluon verwendet wird, um Java auf iOS/Android bereitzustellen) bringt einige Komplikationen mit sich. Native Image muss den gesamten Code bereits zur Kompilierzeit kennen. Dies wird als „Closed-World-Annahme“ bezeichnet. Einige Bibliotheken generieren jedoch Code oder modifizieren ihn zur Laufzeit, wodurch sie mit der Closed-World-Annahme unvereinbar sind. Manche Bibliotheken benötigen auch Zugriff auf Java-Bytecode, der in einem Native Image nicht verfügbar ist. Wieder andere Bibliotheken nutzen Funktionen, die sich im Native Image anders verhalten als in der JVM.

Dadurch verringert sich die Anzahl der verfügbaren Bibliotheken erheblich. Auf der GraalVM-Kompatibilitätsseite sind etwa 270 Maintainer- oder Community-getestete Artefakte aufgeführt. Das bedeutet natürlich nicht, dass nur diese funktionieren. Bibliotheken, die nicht gelistet sind, aber die Closed-World-Annahme erfüllen, sollten alle funktionieren. Frameworks beispielsweise funktionieren häufig nicht, da sie oft Code generieren oder modifizieren. Kleinere Bibliotheken dagegen erfüllen häufiger die Closed-World-Annahme. Diese Einschränkung muss man auch im Kopf behalten, wenn man sich Multiplattform Wasm anschaut.

Java Multiplattform Wasm

Das Wasm-Image unterliegt denselben Einschränkungen wie das Native Image, und weist noch zusätzliche Einschränkungen auf, die durch die Wasm-Laufzeitumgebung auferlegt werden. Einige Plattformaktionen, die in der JVM und nativ verfügbar sind, stehen in einer Wasm-Laufzeitumgebung nicht zur Verfügung. Das liegt daran, dass eines der Sicherheitsziele von WebAssembly darin besteht, Benutzer vor fehlerhaften oder bösartigen Modulen zu schützen, während in Java davon ausgegangen wird, dass ausgeführter Code vertrauenswürdig ist. Daher verfügt die Wasm-Sprache über keine Syscall-Befehle oder integrierte E/A-Funktionen – es gibt keine Möglichkeit, mit der Außenwelt zu kommunizieren. Das bedeutet, dass man keine Dateioperationen durchführen oder die aktuelle Uhrzeit abrufen kann. Wasm-Laufzeit-Embedder (wie das GraalVM-Wasm-Target oder CheerpJ) können jedoch neue Funktionen übergeben, die zusätzliche Funktionen hinzufügen, aber diese sind dann an den Embedder gebunden und verlieren die Portabilität.

Ein Embedder ist ein Programm, das Code in einer Wasm-Laufzeitumgebung ausführt und zusätzliche Funktionen übergibt, die in dieser Laufzeitumgebung genutzt werden können. Das GraalVM-Wasm-Target beispielsweise bettet (verpackt) kompilierten Java-zu-Wasm-Code in ein kleines JavaScript-Programm ein. Dieses Programm startet dann den Code in einer Wasm-Laufzeitumgebung und übergibt eine Reihe von JavaScript-Funktionen, die das kompilierte Java-Programm aufrufen kann. Das bedeutet, dass der Compiler wissen muss, welche Funktionen der Embedder an die Laufzeitumgebung übergibt. Sie sind miteinander verknüpft. Das sieht man im folgenden Beispiel, in dem der Compiler wissen muss, dass der Namespace interop alle Interop-Funktionen enthält.

const wasmImports = {
	interop: {
		'Date.now' : (...args) => Date.now(...args),
		// etc.
	}
};

await WebAssembly.instantiateStreaming(
	fetch("myJavaProgram.wasm"), 
	wasmImports
);

Dieses Problem der Portabilität ist etwas was das WebAssembly System Interface (Wasi) lösen wird. Es handelt sich um eine Reihe von API-Spezifikationen, die man sich wie die Standardbibliothek von Wasm vorstellen kann. Sie wird eine Reihe von minimalen APIs bereitstellen, die Runtime-übergreifend immer vorhanden sein werden. Derzeit (Juni 2026) befinden sich 7 Vorschläge in der Implementierungsphase (Phase 3): Uhren, Zufallszahlen, Dateisystem, E/A, Sockets, Befehlszeilenschnittstelle (CLI) und HTTP. Diese APIs folgen einem Capability-basierten Sicherheitsmodell im Einklang mit den Wasm-Sicherheitszielen, bei dem Modulen nur bestimmte, vorab genehmigte Fähigkeiten gewährt werden (z. B. schreibgeschützter Zugriff auf ein Verzeichnis). Sobald sie Schritt 5 im Phasenprozess erreichen, gelten sie als standardisiert. Das könnte dieses Jahr (2026) geschehen.

Bis dahin hängt es also vom Wasm-Compiler, von der Wasm-Runtime und derzeit auch vom Wasm-Embedder ab, welche Bibliotheken man verwenden kann. Der Compiler muss den Aufruf der Java-Standardbibliothek unterstützen, den die Java-Bibliothek ausführt, und wenn die Standardbibliothek die Außenwelt aufruft, muss die Laufzeitumgebung diesen Aufruf ebenfalls unterstützen (siehe Wasi), oder der Embedder muss ihn weiterleiten.

Java-Multiplattform-JavaScript

CheerpJ bietet eine eigene JDK-Portierung in JavaScript an, unterstützt derzeit jedoch nur das JDK bis zur Version 11 (17 als Preview), was wiederum die Auswahl der Bibliotheken einschränkt, die man verwenden kann. Sie haben jedoch das Potenzial ihres Ansatzes unter Beweis gestellt, indem sie die 400 MB großen IntelliJ-JAR-Dateien und eine unveränderte Minecraft-JAR-Datei im Browser ausführen konnten.

Kotlin Multiplattform

Wenn Kotlin für plattformübergreifende Ziele wie iOS kompiliert wird, kann es keine JVM-Bibliotheken mehr verwenden. Auf diesen anderen Plattformen benötigt Kotlin KMP-Bibliotheken. Nicht alle Kotlin-Bibliotheken sind plattformübergreifend. Entwickler müssen sich explizit dafür entscheiden, indem sie nur andere plattformübergreifende Bibliotheken verwenden und Produktionscode in src/commonMain/kotlin statt in src/main/kotlin ablegen. Es gibt etwa 3000 solcher Bibliotheken, darunter Ktor (Client-/Server-Anwendungen), kotlinx.serialization (z. B. JSON-Serialisierung), Sqldelight (Datenbank), Compose (Multiplattform-Benutzeroberflächen) und TestBalloon (Multiplattform-Tests). Zum Vergleich: Andere plattformübergreifende Ökosysteme haben 2300 (React Native) und 35 000 (Flutter) Pakete.

Fazit

Es gibt keine native Möglichkeit, Java auf Android, iOS oder in einem Webbrowser auszuführen. Dafür ist man auf andere Anbieter angewiesen.

Derzeit scheinen Java-Bibliotheken auf iOS/Android die beste Unterstützung zu erhalten, wenn sie mit der nativen Kompilierung von Gluon (einem Drittanbieter) verwendet werden. Allerdings funktionieren nicht alle Bibliotheken, wenn sie nativ kompiliert werden. Derzeit gibt es nur 270 getestete native Artefakte, und es existiert keine Liste, welche Bibliotheken auf Mobilgeräten funktionieren.

Java-Bibliotheken im Web Frontend sind ein vielschichtiges Thema. TeaVM unterstützt nur einen Teil der Java-Standardbibliothek, was die Auswahl an Bibliotheken einschränkt. CheerpJ unterstützt derzeit nur das JDK bis Version 11, was die Auswahl an Bibliotheken ebenfalls einschränkt, aber auch beeindruckende Demos von IntelliJ und Minecraft im Browser bietet. Schließlich ist die Konvertierung von Java zu Wasm zwar möglich, befindet sich jedoch derzeit noch im experimentellen Stadium und wird von Tools von Drittanbietern (GraalVM) bereitgestellt.

In Kotlin ist die Situation einfacher. Kotlin verfügt über etwa 3000 plattformübergreifende Bibliotheken, die auf allen Zielplattformen funktionieren. Im Vergleich zu anderen plattformübergreifenden Ökosystemen ist das ein guter Stand, bietet aber noch viel Raum für Wachstum, insbesondere für seltene Anwendungsfälle und spezialisierte Bereiche.

Multiplattform Zusammenfassung

Für jede der Plattformen ergeben sich folgende Bewertungen:

Javas „Run Anywhere“-Konzept beschränkt sich auf den Desktop. Für weitere Plattformen sind experimentelle oder von Drittanbietern stammende Tools erforderlich. Kotlin hebt sich deutlich ab, da es über ein einheitliches, offiziell unterstütztes plattformübergreifendes Konzept für Logik und Benutzeroberfläche verfügt. Es erweitert die Java-Welt mit einer einzigen Sprache und gemeinsamen UI-Frameworks auf Android, iOS, den Desktop und WebAssembly und ist damit die bessere Wahl, wenn plattformübergreifende Apps benötigt werden, die über den traditionellen JVM-Server-/Desktop-Bereich hinausgehen.

Im nächsten Teil dieser Reihe geht es um die Möglichkeiten beider Sprachen zur Modellierung der Geschäftslogik.