Kotlin kontra Java – Teil 1 – Ökosystem

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

Kotlin wird von Amazon, Atlassian, Duolingo, Google, JetBrains, Meta, Netflix, Uber und vielen anderen genutzt. Java wird von, nun ja, „mehr als 3 Milliarden Geräten“ verwendet. Welche Sprache bietet den größten Nutzen, welche verschafft uns einen Vorteil, für welche sollten wir uns entscheiden?

Nach 20 Jahren der Systementwicklung in Java und 8 Jahren in Kotlin habe ich miterlebt, wie sich Kotlin seinen Ruf als natürliche Weiterentwicklung von Java verdient hat. Zu Recht. Vieles, was im Projektalltag benötigt wird, lässt sich in Kotlin klar und prägnant ausdrücken.

Aber eine Sprache ist nicht nur ihre Syntax. Es geht nicht nur darum, wie gut wir Geschäftslogik in der Sprache modellieren können, wie prägnant der geschriebene Code ist oder ob wir Semikolons schreiben müssen. Es geht auch um die Tools, die sie umgeben, wen wir um Hilfe bitten können und welche Bibliotheken wir nutzen können. Kurz gesagt: Bei einer Programmiersprache geht es auch um das Ökosystem.

In diesem Artikel werden wir das Ökosystem von Java und Kotlin vergleichen. Teil 2 widmet sich den Multiplatform-Fähigkeiten beider Sprachen, Teil 3 nimmt die Modellierungsfähigkeiten unter die Lupe, bevor wir schließlich ein Urteil darüber fällen, welche Sprache man im Jahr 2026 wählen sollte.

Bewertungskriterien für das Ökosystem

Programmiersprachen sollten idealerweise folgende Eigenschaften aufweisen:

1. Langlebigkeit mit guter Abwärtskompatibilität
2. Verfügbarkeit von Entwicklern und attraktive Community
3. IDE-Unterstützung auf hohem Niveau
4. Performance – zur Laufzeit und bei der Entwicklung
5. Ausgereifte Bibliotheken und Frameworks

Schauen wir uns die einzelnen Punkte genauer an.

Langlebigkeit

Langlebige Programmiersprachen müssen mit der Entwicklung der Softwaremodellierung Schritt halten – etwa durch neue Syntax, Bibliotheken und Werkzeuge für gängige Anwendungsfälle. Gleichzeitig müssen sie die Abwärtskompatibilität zu früheren Versionen wahren. Entscheidend ist dabei nicht ein möglichst schneller Release-Rhythmus, sondern ein ausreichend schneller.

Java

Man kann mit Fug und Recht behaupten, dass Java – ursprünglich von Sun Microsystems, heute von Oracle weitergeführt – eine lange Lebensdauer hat. Version 1 wurde 1996 veröffentlicht. In diesem Jahr werden die Versionen 26 und 27 erscheinen. Hauptversionen werden alle sechs Monate veröffentlicht. Diese Releases sind jedoch bewusst konservativ, was den Umfang der Änderungen angeht. Jede neue Funktion muss potenziell für immer unterstützt werden und Java hat bereits sehr viele Funktionen, auch viele die bis heute Probleme für die Maintainer machen (z.B. sun.misc.Unsafe oder die Serialization Api). Neue Funktionen durchlaufen daher mehrere Preview-Versionen (davor manchmal auch mehrere Inkubations-Versionen), bevor sie als stabil freigegeben werden. Im Laufe der Jahre wurden damit viele wichtige Funktionen hinzugefügt. Diese Sprache wird so schnell nicht verschwinden.

Die Maintainer legen großen Wert auf Abwärtskompatibilität und vermeiden Breaking Changes weitgehend. So können beispielsweise sogar Bibliotheken, die interne JDK-Funktionen nutzen und nie für die Öffentlichkeit bestimmt waren, weiterhin verwendet werden. Die Maintainer haben lediglich die Defaulteinstellung geändert, und wir müssen invasive Eingriffe in JDK-Interna über Flags wie --add-opens aktivieren. Wenn Funktionen entfernt werden (z. B. CORBA, Nashorn JavaScript Engine, siehe Eine visuelle Zeitreise durch die Entwicklung des JDK), geschieht dies nur, wenn sich praktikable Alternativen bereits etabliert haben. So lassen sich Upgrades im eigenen Tempo planen, ohne jeder neuen Version hinterherlaufen zu müssen.

Viele Unternehmen gehen entsprechend vor und wählen einen langsamen Upgrade-Pfad. New Relics State of Java Ecosystem 2024 legt nahe, dass 28,8 % immer noch JDK 8 (veröffentlicht 2014) verwenden, 32,9 % JDK 11 (2018) und nur 35,4 % Java 17 (2021).

Kotlin

Im Vergleich dazu ist Kotlin – entwickelt von JetBrains – erst 10 Jahre alt. Version 1 wurde 2016 veröffentlicht, und die Versionen 2.3 und 2.4 werden noch in diesem Jahr erscheinen. Hauptversionen werden alle sechs Monate veröffentlicht, ähnlich wie bei Java. Tool-Releases folgen drei Monate nach dem Hauptrelease. Viele der Funktionen, über die Kotlin bereits verfügt, sind Dinge, auf die Java hinarbeitet, wenn auch in anderer Form. In den letzten Jahren ist Kotlin allerdings etwas konservativer mit neuen Funktionen geworden und stabilisiert diese erst nach mehreren Previews (experimental → Alpha → Beta). Google hat Kotlin stark unterstützt, indem es die Sprache 2019 zur Standard-Programmiersprache für Android gemacht hat. Google, JetBrains, Meta, Gradle, Uber, Kotzilla und Block sind zudem Mitglieder der Kotlin Foundation, die „die Entwicklung der Programmiersprache Kotlin schützt, fördert und vorantreibt“. Auch diese Sprache wird so schnell nicht verschwinden.

Kotlin unterscheidet sich jedoch ein wenig von Java. Es lässt sich zwar in Java-Bytecode kompilieren (alle Versionen zwischen Java 8 und 25 werden unterstützt), verfügt jedoch nicht über eine virtuelle Maschine, die diesen Bytecode ausführen kann (wenn man MultiPlattform außer Acht lässt — mehr dazu in Teil 2). Dies hat Auswirkungen auf den Release-Prozess. JetBrains behandelt die Sprache wie einen Compiler, und nur die neueste Version erhält Bugfixes. Wenn Nutzer neue Sprachfunktionen, neue Standardbibliotheksfunktionen oder die Unterstützung neuerer JDKs wünschen, müssen sie ein Update durchführen.

JetBrains hat in den Kotlin-Entwicklungsgrundsätzen zugesichert, Updates komfortabel zu gestalten: Breaking Changes werden frühzeitig angekündigt, sind im Code mit der Annotation @Deprecated gekennzeichnet und es gibt eine automatisierte Migration. Ich habe selten Breaking Changes erlebt, und wenn sie auftreten, war der Migrationspfad sehr angenehm. Kotlin hat dafür die @Deprecated-Annotation um das Attribut replaceWith erweitert. Wenn eine Api ersetzt werden muss, teilt dieser Parameter der IDE mit, womit sie ersetzt werden soll. Sehr komfortabel.

Fazit

Zusammenfassend lässt sich sagen, dass beide Sprachen eine ähnliche Lebensdauer erwarten lassen. Java bietet stärkere Garantien hinsichtlich der Abwärtskompatibilität, was angesichts seines deutlich höheren Alters und seiner größeren Nutzerbasis von Bedeutung ist. Kotlin profitiert hingegen von einer guten IDE-Integration, die Migrationen nahezu reibungslos gestaltet.

Verfügbarkeit von Entwicklern

Verfügt die Programmiersprache über genügend Entwickler, verfügen diese über nennenswerte Erfahrung und besteht genügend Interesse, damit neue Entwickler hinzukommen? Um diese Fragen zu beantworten, betrachten wir drei viel zitierte Umfragen, die zusammen Aktivität, Interesse und tatsächliche Nutzung abdecken:

• Redmonk-Umfrage, die GitHub Pull Request und Stack Overflow Aktivität misst
• IEEE Spectrum-Umfrage, die versucht, das Interesse anhand von Suchanfragen, Stellenanzeigen usw. zu messen
• Stack Overflow-Umfrage, die fragt, ob die Entwickler umfangreiche Arbeit in der Sprache geleistet haben.

Die folgende Rangliste zeigt Java unter den Top 8 und Kotlin unter den Top 15. Rust, das 2015 veröffentlicht wurde, ist ebenfalls enthalten, sodass wir eine weitere relativ neue Sprache als Maßstab dafür haben, wie „neue“ Ökosysteme dennoch Talente anziehen können.

Wenn wir uns den Developer Ecosystem Data Playground von JetBrains ansehen, spiegeln sich diese Ranglisten in den Daten wider. Hier gibt es etwa 20,8 Millionen Menschen, die in irgendeiner Form programmieren. Etwa 7,1 Millionen Menschen geben an, dass Java ihre Hauptsprache ist, und etwa 2 Millionen sagen, dass es Kotlin ist.

Fazit

Die Ergebnisse sind ermutigend. Wir können jede der beiden Sprachen wählen und Entwickler finden, die sie nutzen, Interesse daran haben und bereits umfangreiche Erfahrungen damit gesammelt haben. Meiner Erfahrung nach ist die Syntax von Kotlin für Java- (und JavaScript-)Entwickler so vertraut, dass die Einarbeitung in ein neues Projekt ein schneller Prozess ist, der sich in Wochen und nicht in Monaten bemisst.

IDE-Unterstützung

Java

Java verfügt über eine sehr gute IDE-Unterstützung. Es wird von IntelliJ, Eclipse und NetBeans standardmäßig unterstützt. Alternative Editoren (wie Visual Studio Code oder Vim/NeoVim) können Sprachunterstützung über einen Language Server erhalten. Einer davon wird von der Eclipse Foundation, Red Hat und Microsoft gepflegt. Ein weiterer wird von Apache NetBeans gepflegt. Red Hat stellt außerdem ein VS Code-Plugin bereit, während die Community eine NeoVim-Erweiterung bereitstellt.

Kotlin

Kotlin wird von JetBrains entwickelt, dem Hersteller der hervorragenden IntelliJ-IDE (die auch die Grundlage für das kostenlose Android Studio bildet). Laut dem JRebel 2025 Java Developer Productivity Report nutzen 84 % der Java-Entwickler diese IDE, gefolgt von 31 % mit VS Code und 28 % mit Eclipse (die Auswahl mehrerer IDEs war erlaubt). Die Unterstützung in der eigenen IDE ist hervorragend und mindestens genauso gut wie für Java.

Aber wie sieht es mit alternativen IDEs aus? Zum einen bietet JetBrains ein Eclipse-Plugin an. Zum anderen stellen sie nun einen offiziellen Language Server zur Verfügung (wenn auch noch in der Pre-Alpha-Phase), ein VS-Code-Plugin (noch nicht im Marketplace veröffentlicht) und einen VS-Code-Konverter von Java nach Kotlin. Es gibt zwar einen Community Language Server, der jedoch zugunsten des offiziellen Servers als veraltet markiert wurde.

Fazit

Insgesamt stehen Java-Anwendern mehrere ausgereifte, funktionsreiche Entwicklungsumgebungen für verschiedene Plattformen zur Auswahl. Die Kotlin-Unterstützung ist in IntelliJ-basierten IDEs und in Eclipse am besten, während die Unterstützung in anderen Editoren derzeit auf einem offiziellen Sprachserver basiert, der sich noch in der Pre-Alpha-Phase befindet und bei dem einige Funktionen noch fehlen.

Performance zur Entwicklungszeit

Um schnell Feedback zu erhalten, brauchen wir eine schnelle Kompilierung. Ohne ein kompiliertes Programm (d. h. Bytecode) können wir weder unsere Tests ausführen noch die Anwendung starten.

Benchmarking ist knifflig

Laut Ad-hoc-Benchmarks des Mill-Build-Tools kann javac (der Java-Compiler) 100.000 Zeilen pro Sekunde Java-Code kompilieren.

Sobald jedoch ein Build-Tool wie Gradle oder Maven zum Einsatz kommt, sinkt diese Zahl auf 9.000 bzw. 6.000 Zeilen pro Sekunde. Ein Grund dafür ist, dass javac nicht „hot“ gehalten wird, sondern immer einen Kaltstart durchläuft, was den üblichen Java Startup-Overhead mit sich bringt. Java-Programme sind dafür bekannt, dass sie einige Zeit benötigen, um ihre Spitzenleistung zu erreichen, und der Compiler bildet da keine Ausnahme. Der andere Grund ist, dass Build-Tools weit mehr leisten als der Compiler, darunter Abhängigkeitsmanagement, Modulauflösung, Aufgaben-/Phasenauflösung, Caching und Invalidierung.

Aufbau des Benchmarks

Es ist schwierig, allein die Leistung des Compilers zu vergleichen, da die meisten Projekte Abhängigkeiten nutzen, in Module unterteilt sind und spezielle Aufgabenanforderungen haben. Im Rahmen dieses Artikels werde ich mich auf den Vergleich der Ausführungsgeschwindigkeit von Gradle konzentrieren, normiert nach der Anzahl der Codezeilen. Statt synthetischer Beispiele vergleiche ich zwei reale Open-Source-Projekte.

Das Java-Beispielprojekt ist Mockito (enthält 63.984 Java-RLoC). Mockito enthält außerdem etwa 2.299 Kotlin-RLoC, die für diesen Vergleich jedoch als unerheblich angesehen und ignoriert werden. Das Beispiel-Kotlin-Projekt ist Exposed (97.204 Kotlin-RLoC). Beide sind Gradle-Projekte mit 25 (Mockito), beziehungsweise 21 (Exposed) Subprojekten.

Tokei wird verwendet, um die tatsächlichen Codezeilen (RLoC), d. h. reine Codezeilen, zu zählen. Kommentare und Leerzeilen werden ausgeschlossen, da sie für den Compiler nicht relevant sind. Die Anzahl der Gradle-Projekte wird durch Ausführen von ./gradlew projects ermittelt. Die Abhängigkeiten des Projekts werden über ./gradlew :*:dependencies abgerufen. Die Gradle-Version und die Daemon-JVM werden über ./gradlew --version ermittelt.

Der Befehl ./gradlew classes testClasses wird einmal ausgeführt, um alle Abhängigkeiten herunterzuladen. Anschließend wird die Netzwerkverbindung deaktiviert und der folgende Befehl wird fünfmal für beide Projekte auf demselben Rechner ausgeführt:

./gradlew clean && time ./gradlew classes testClasses --no-build-cache

Der Median dieser fünf Durchläufe wird anschließend anhand der tatsächlichen Zeilenzahl normiert. Nach erfolgreichem Build wird die Anzahl der ausgeführten Aufgaben erfasst.

Fazit

Mockito (Java) wird mit einem Median von 4 294 Zeilen/s und Exposed (Kotlin) mit einem Median von 5 849 Zeilen/s kompiliert. Bei diesen beiden spezifischen Projekten kompiliert Kotlin also etwa 36 % schneller als Java. Nur aus diesen zwei Beispielen kann man natürlich nicht verallgemeinern, dass „Kotlin schneller als Java kompiliert“. Vielleicht wirkt Kotlin hier schneller, weil sich der fixe Gradle-Overhead bei Exposed auf 52 % mehr Codezeilen amortisiert. Was dieser Benchmark allerdings zeigen kann, ist, dass der Kotlin-Compiler performant ist.

Bemerkenswert ist auch, dass beide Median-Kompilierungszeiten langsamer sind als die von den Mill-Maintainern gemessenen Werte, was jedoch auf unterschiedliche Hardware-Konfigurationen zurückzuführen sein kann. Es wäre interessant, eine eingehende Untersuchung mit viel mehr Projekten durchzuführen, vielleicht sogar unter vollständiger Umgehung von Gradle und unter direkter Verwendung von javac und kotlinc.

Dennoch scheint die mit Kotlin 2.0 eingeführte Neugestaltung des Kotlin-Compilers ein Erfolg gewesen zu sein. JetBrains kündigte an, dass damit im Vergleich zu 1.9 eine Beschleunigung der Kompilierung um bis zu 94 % erzielt werden könne.

Zusammenfassend bieten sowohl Java als auch Kotlin eine vergleichbare Kompilierungsgeschwindigkeit, unsere Build-Tools haben jedoch noch Verbesserungspotenzial.

Performance zur Laufzeit

An dieselbe JVM gebunden

Da sowohl Java als auch Kotlin auf derselben JVM laufen, ist ihre Laufzeitleistung ebenfalls an diese Maschine gebunden. Das hat Vor- und Nachteile.

Es ist ein Nachteil, weil derselbe Startup (Zeit bis zur ersten nutzbaren Arbeit), dasselbe Warmup (Zeit bis zum Erreichen der Spitzenleistung), dieselbe Skalierbarkeit (Durchsatz pro Ressource) und derselbe Speicherverbrauch beide Sprachen gleichermaßen zur Laufzeit beeinflussen.

Es ist aber auch ein Vorteil, denn alle Verbesserungen der JVM können beiden Sprachen zugute kommen. Das gilt für Startup (z. B. CRaC), Warmup (z. B. AOT-Caching), Skalierbarkeit (z. B. Z Garbage Collector, Shenandoah, Virtual Threads, Integrity by Default) und Speicherverbrauch (z. B. Valhalla).

Kotlin kann dies natürlich mit seinem Compiler verbessern, allerdings nur bis an die Grenzen des Bytecodes. So hat Kotlin beispielsweise Coroutinen eingeführt (Kotlin 1.3, Okt. 2018), die den Durchsatz von Eingabe/Ausgabe-gebundenen Anwendungen steigern – lange bevor Java Virtual Threads hinzufügte (JDK 21, Sep. 2023). Diese konnten jedoch zum Beispiel das Thread-Pinning (mit synchronized-Methoden, die einen Thread für E/A-Vorgänge blockieren) nicht umgehen, bis das JDK dieses Problem löste (JDK 24, März 2025). Ein anderes Beispiel sind value classes, die Kotlin bereits besitzt (Kotlin 1.5, Mai 2021). Diese sind derzeit noch ein reines Design-Time Feature und werden vom Compiler inline gesetzt. Eine value class User(val rawName: String) wird nach der Kompilierung zu einem val rawName: String. Der Compiler kann nichts weiter tun, bis das JDK den Bytecode der tatsächlichen Werttypen stabilisiert hat.

Kotlin kann natürlich auch die Leistung verschlechtern, indem es zu ineffizientem Bytecode kompiliert, daher sollten wir uns zumindest einige Leistungsvergleiche ansehen.

Das Benchmarking der Ausführung ist knifflig

Die meisten Geschäftsanwendungen sind E/A-gebunden. Sie empfangen eine Eingabe (in der Regel eine Webanfrage), führen eine einfache Verarbeitung durch, schreiben die Ausgabe in eine Datenbank und geben dann eine Antwort auf die Webanfrage Aus. Eine Programmiersprache muss daher meist nicht hochperformant sein, sie muss nur gut mit E/A umgehen können. Genau diese Situation versuchen reaktive Streams (JDK 9, 2017), Coroutinen und virtuelle Threads zu lösen. Dabei geht es jedoch nicht um Leistung, sondern um Effizienz. Jede E/A-Operation bedeutet, dass unsere Anwendungslogik auf das Ergebnis wartet und nichts tut. Der Prozessor ist dann inaktiv. Reactive Streams/Coroutinen/virtuelle Threads nutzen das aus, indem sie den Thread für eine andere Operation nutzen, bis die E/A-Operation ein Ergebnis zurückgibt. Effizient.

In manchen Fällen kann unsere Anwendung jedoch CPU-gebunden sein. Das Codieren/Decodieren von Informationen oder das Multiplizieren riesiger Matrizen sind Beispiele hierfür.

Beim Schreiben solcher CPU-lastigen Codes müssen wir oft einen Kompromiss zwischen Geschwindigkeit und Lesbarkeit eingehen. Die ausschließlich für Java gedachte „One Billion Rows Challenge“ (1BRC) veranschaulicht dies sehr gut. Wir müssen eine .txt-Datei mit einer Milliarde Zeilen Temperaturmessungen pro Wetterstation einlesen und für jede Wetterstation den Minimal-, Mittel- und Maximalwert berechnen. Eine Version, deren Ausführung etwa 13 Sekunden dauert, hat 11 Funktionen und umfasst etwa 250 Zeilen Code. Sie ist recht gut lesbar. Der Gewinner der Challenge benötigt jedoch etwa 2 Sekunden, hat 23 Funktionen und 435 Codezeilen und manipuliert seinen eigenen Speicher über sun.misc.Unsafe. Er ist deutlich weniger lesbar.

Wenn wir uns also Leistungsbenchmarks ansehen, sollten wir beachten, dass jedes Ergebnis durch die Erstellung von weniger lesbarem Code leistungsfähiger gemacht werden könnte. Diese Benchmarks liefern uns lediglich einen groben Anhaltspunkt für das Verhältnis der Ausführungszeiten dieser Sprachen.

Benchmarks

Es gibt zahlreiche Sprach-Benchmarks, darunter die Benchmarks für Programmiersprachen und Compiler, das Benchmarks-Spiel und der Energieeffizienz-Benchmark. Hier wird kostya/benchmarks verwendet, da der Code hier „so geschrieben ist, wie es ein durchschnittlicher Softwareentwickler tun würde“:

• Die Algorithmen sind so implementiert, wie sie in öffentlichen Quellen beschrieben sind

• Die Bibliotheken werden so verwendet, wie es in den Tutorials, der Dokumentation und den Beispielen beschrieben ist
• Die verwendeten Datenstrukturen sind idiomatisch

Einige Sprachen neben Java und Kotlin sind als Referenz enthalten – darunter Scala, das ebenfalls auf der JVM läuft. In der Original-Tabelle gibt es noch „Staged“ Ergebnisse. Diese werden ausgeschlossen, da diese nur zu Testzwecken dienen und keinen Aufschluss über die tatsächliche Leistung geben.

Fazit

Java und Kotlin bieten in diesen Benchmarks in etwa die gleiche Leistung. In den drei Benchmarks liegt Java um etwa 0,1 Sekunden vorn. Für die meisten, wenn nicht sogar alle Geschäftsanwendungen ist dieser Unterschied vernachlässigbar.

Ausgereifte Bibliotheken und Frameworks

Ein ausgereiftes Ökosystem verfügt über eine Fülle von Bibliotheken und Frameworks – eine solide Grundlage, auf der wir aufbauen können. Java bietet einen umfangreichen Katalog mit rund 800.000 Paketen für vielfältige Themenbereiche wie Web, Authentifizierung, Datenbanken, Tests, Serialisierung, Validierung und Mapping. Kotlin auf der JVM verfügt ebenfalls über all diese Komponenten. Jede Java-Bibliothek kann in Kotlin verwendet werden, da Kotlin großen Wert auf Interoperabilität legt (wie wir in Teil 3 sehen werden).

Ein java.util.List in Java ist ein kotlin.collections.List in Kotlin. Ein java.util.Map in Java ist ein kotlin.collections.Map. Keine Konvertierung ist erforderlich. Dies unterscheidet Kotlin von anderen JVM-Sprachen wie Scala oder Clojure, bei denen die Standardbibliotheken nicht kompatibel sind und konvertiert werden müssen.

Frameworks wie Quarkus und Spring bieten erstklassige Unterstützung für Kotlin, was sie mit umfangreichen Kompatibilitätstests überprüfen. Außerdem bedeutet diese Unterstützung:

• viele Komfortmethoden bereitstellen, damit sich das Framework in Kotlin idiomatischer anfühlt
• Unterstützung für Kotlin-Coroutinen
• die Verwendung der JSpecify-Annotationen @Nullable (Wert kann null sein) und @NonNull (Wert kann nie null sein)

Letzteres bedeutet, dass Kotlins Nullsicherheit auch mit Java-Bibliotheken funktioniert.

Fazit

Kotlin kann genau denselben ausgereiften Katalog an Bibliotheken und Frameworks nutzen wie Java. Darüber hinaus verfügt Kotlin über eine wachsende Sammlung von Multiplatform-Bibliotheken, die wir in Teil 2 betrachten werden.

Ökosystem Zusammenfassung

Sollten wir uns für Java oder Kotlin entscheiden? Wenn wir uns das Ökosystem ansehen, ergibt sich folgende Tabelle:

Auf der JVM allein sind sich Java und Kotlin hinsichtlich der zu erwartenden Lebensdauer, ausgereifter Bibliotheken sowie der Kompilierungs- und Laufzeitleistung ähnlich. Java hat derzeit die Nase vorn, was die Verfügbarkeit von Fachkräften und die Breite der Editor-Unterstützung angeht; Kotlin punktet mit Tempo, Benutzerfreundlichkeit und Migrationswerkzeugen, insbesondere in den JetBrains-IDEs. Für Teams, die noch auf JDK 8 festsitzen, hat Kotlin einen deutlichen Vorsprung, da es einer 12 Jahre alten Laufzeitumgebung moderne Funktionen mit vertrauter Syntax bietet.

Wo sich Kotlin deutlich abhebt, ist die Multiplatform-Entwicklung, wie wir in Teil 2 sehen werden. In diesem Teil werden wir uns auch die Multiplatform-Bibliotheken und Frameworks ansehen.

In Teil 3 werden wir untersuchen, wie gut wir Geschäftslogik mit beiden Sprachen modellieren können, und schließlich ein endgültiges Urteil fällen.