Kotlin

Lucas Dohmen: Hallo und willkommen zu einer neuen Folge des innoQ Podcasts, heute habe ich den Jörg zu Gast. Hallo Jörg.

Jörg Müller: Hallo Lucas.

Lucas Dohmen: Wir wollen heute über die Programmiersprache Kotlin sprechen, aber bevor wir damit anfangen, magst du dich kurz vorstellen?

Jörg Müller: Mein Name ist Jörg Müller und ich bin Principal Consultant bei der innoQ. Meine aktuellen Schwerpunkte sind eher DevOps Themen, Aufbau von Infrastrukturen und Plattformen für Microservices-Umgebungen, aber ich programmiere seit einigen Jahren auch auf der JVM in Java, aber auch in einigen anderen Sprachen wie Clojure oder Groovy. Das ist auch der Weg, wie ich auf das Thema Kotlin gekommen bin.

Lucas Dohmen: Okay, bevor wir da tiefer einsteigen, magst du uns sagen, was denn Kotlin ist und wo es eigentlich her kommt?

Jörg Müller: Kotlin ist eine Programmiersprache, die von der Firma JetBrains entwickelt wurde, so circa im Jahre 2010 für ihre Entwicklungsumgebung, wo sie eine alternative Programmiersprache gesucht haben, mit der sie etwas produktiver arbeiten können. Sie haben sich nach ihrer eigenen Aussage damals einige Sachen angeschaut, u.a. Scala, was damals sicherlich einer der besten Kandidaten gewesen wäre, und haben dann festgestellt, dass die Sprache nicht besonders leicht “toolable” ist, wie sie sich ausgedrückt haben. Und sie hatten auch die Befürchtung, dass so viele Features darin existieren, dass es schwierig wird, das wirklich in einem größeren Maßstab umzusetzen.

Daraufhin haben sie sich überlegt, was sie machen können, haben sich umgeschaut, haben sich sehr viele Features anderer Sprachen an- und abgeschaut, und haben dann eine eine eigene Sprache entwickelt, die von Anfang an IDE Unterstützung etc. hatte. Die Sprache ist Open Source und unter eine Apache-2-Lizenz veröffentlicht und ist relativ lange entwickelt worden, bis zu einer Version 1.0, die im Februar 2016 rauskam. Mittlerweile ist die Sprache relativ groß und wird auch sehr intensiv weiterentwickelt; bei JetBrains ist es wohl das zweitgrößte Team, was sie haben, mit ungefähr vierzig Leuten und auf GitHub gibt es über 180 Committer zu dieser Programmiersprache. Zu besonderem Ruhm ist die Sprache dieses Jahr auf der Google I/O gelangt, nachdem sich Google entschieden hat, Kotlin zur dritten offiziell unterstützen Sprache nach Java und C++ unter Android zu machen, was als Schritt von der Android Community sehr begrüßt worden ist und von einigen als eine gewisse Reaktion auf das Thema Swift von Apple gesehen wurde.

Lucas Dohmen: Das bedeutet, es läuft schon mal auf der JVM und irgendwie auf Android. Wo läuft denn Kotlin noch so, oder ist das das einzige Target?

Jörg Müller: Also die JVM ist das, wo Kotlin her kommt. Und interessanterweise ist es auch auf älteren Versionen der JVM sehr stark implementiert worden. Der Hintergrund ist wahrscheinlich Android, vermute ich mal. Man kann Kotlin in all seinen Features bereits auf einem Java 1.6 laufen lassen. Sie haben sich aber mittlerweile sehr viele andere Alternativen angeschaut oder umgesetzt oder setzen sehr stark auf das Thema Multiplattform. Da geht es einmal um JavaScript: Es gibt eine Variante, bei der man Kotlin nach JavaScript cross-kompilieren kann, wie es das wahrscheinlich inzwischen bei fast jeder anderen Programmiersprache gibt. Es gibt auch eine Variante von Kotlin, Native, also mit einem LLVM Backend - beides noch relativ jung, allerdings stark fokussierte Themen von JetBrains.

Lucas Dohmen: Okay, warum möchte man sich denn sie Sprache anschauen? Ich meine, heutzutage hat man Auswahl zwischen so vielen Sprachen, da muss man sich schon gut überlegen, was man sich da anschaut. Warum würdest du sagen, lohnt es sich, Kotlin anzuschauen?

Jörg Müller: Ich denke speziell, wenn man im Bereich JVM unterwegs ist und vielleicht eine alternative Programmiersprache sucht, ist Kotlin einen wunderbare Alternative: Sie ist einfacher, sie ist näher an den typischen heutigen Programmiersprachen dran, wie Swift, Rust, Scala etc., bietet dabei aber gleichzeitig eine sehr schöne Interoperabilität mit Java, hat einen hervorragenden IDE Support und läuft eben auch noch auf den alten Versionen von der JVM. Alles in Allem, denke ich, wenn man bisher den Schritt noch nicht gewagt hat, sich eine andere Sprache dort anzuschauen, ist das eine Sprache, vor der man nicht Halt machen sollte.

Lucas Dohmen: Dann lass uns doch jetzt ins Detail gehen: Was für Features hat denn Kotlin und was macht sie vielleicht besonders im Vergleich zu anderen Programmiersprachen, und auch insbesondere im Vergleich zu Java, wo es dann eine Alternative zu bildet?

Jörg Müller: Genau, vor allem der Vergleich zu Java ist hier interessant, glaube ich, weil viele von den Features, die ich jetzt aufzählen werde, wird man von modernen Programmiersprachen bereits kennen. Also, ein Trend, den man auch von Scala schon kennt, ist der, das diese Sprache sehr stark auf Type Inference setzt. Mir fällt gerade ein, dass wir noch nicht erwähnt haben, dass Kotlin eine statisch typisierte Sprache ist, sonst würde es sicherlich keine Rolle spielen, aber durch das Thema Type Inference bekommt man dort eine ähnliche Kompaktheit des Codes hin und eine ähnliche Einfachheit das ganze zu schreiben, wie man das von dynamisch typisierten Sprachen kennt.

Es gibt Dinge wie Top-Level-Funktionen. Man muss also, wenn man einfach nur eine Funktion haben will, das ganze nicht wieder zwangsläufig in eine Klasse einpacken. Das machen sie auch sehr geschickt mit der Implementierung auf der JVM. Also man kann das ganze dann trotzdem relativ leicht aus Java heraus aufrufen, weil es eigentlich nur statische Methoden sind. Man kann Klassen sehr kompakt definieren, auch das etwas, was man zum Beispiel von Scala oder Groovy bereits kennt, was diese Sprache sehr geschickt übernommen hat. Das heißt um eine einfaches POJO zu definieren, schreibt man im Prinzip nur “class”, den Namen und in Klammern dahinter die Properties, die man benötigt. Wenn man dann das ganze noch mit equals und hashcode etc. ausstatten möchte, schreibt man einfach noch ein data vor das class und schon hat man etwas, wofür man in Java eine Menge Code schreiben oder sich generieren lassen muss.

Man kann mehrere Klassen in ein File reinbringen, etwas, was in der Java-Welt immer etwas merkwürdig war im Vergleich zu anderen Sprachen. Es gibt solche Dinge wie “String Templates”, wie wir sie auch aus Groovy kennen, das heißt man schreibt einen String und darin einfach ${variablenName}. Man kann sich also sehr leicht Dinge zusammensetzen.

Was ich sehr spannend umgesetzt finde, ist das gesamte Thema Default-Argumente und Named-Argumente, was an sich in vielen Programmiersprachen nichts besonderes ist, aber eine Menge Boilerplate-Code auf diese Weise verhindert. Wenn man eine Methode schreibt, bei der bestimmte Argumente optional sind, kann man ihnen Default-Values und einen Namen geben, was dazu führt, dass man sich viele Overloaded-Functions schlichtweg sparen kann. Was dann aber Kotlin wieder ganz nett macht, ist, dass es trotzdem in der Lage ist, Stubs zu generieren, die man dann wiederum aus Java als ganz normale Overloaded-Functions verwenden kann. Hier wurde immer sehr stark darauf geachtet das ganze kompatibel mit Java und der Java-Umgebung zu halten. Es gibt natürlich Lambdas, die gibt es auch wenn man das JDK 1.6 einsetzt - ich glaube, das ist eine der Besonderheiten an dieser Stelle, man kann aber auch dort relativ leicht die Funktionserweiterung von Java 8 verwenden. Da gibt es entweder die Möglichkeit, die Kotlin eigenen Extensions, die ich gleich noch erwähnen werde, zu verwenden, oder eben auch die Dinge aus Java heraus und es fühlt sich sehr ähnlich an. Natürlich gibt es auch Dinge wie Generics etc., was man von so einer Programmiersprache de facto erwarten kann.

Lucas Dohmen: Du hattest am Anfang gesagt, dass es auch eine gute Interoperabilität mit Java gibt, bedeutet das, ich kann Java-Klassen einfach so verwenden, als wären sie aus Kotlin oder wie muss ich mir das vorstellen?

Jörg Müller: Ja, die einzige Besonderheit, da komme ich noch drauf, ist Nullability, aber ansonsten kann ich Java-Klassen ganz einfach in Kotlin-Code verwenden. Die Tool-Unterstützung dazu, ist sogar ganz interessant: Wenn man IntelliJ benutzt ist die Tool-Unterstützung generell fast auf dem selben Level wie bei Java und es hat dann auch so kleine Gimmicks wie: Ich nehme mir Java-Code, kopiere ihn und paste ihn in ein Kotlin File, dann bietet mir die IDE an, das gleich in Kotlin-Code zu konvertieren. Und das funktioniert auch relativ gut und ist ein schöner Startpunkt, wenn man bestimmten alten Code konvertieren möchte in Richtung Kotlin.

Lucas Dohmen: Ja, das klingt nach einem coolen Feature. Ich meine, der IDE Support wird ja vermutlich hervorragend sein, wenn man sich überlegt, wer da so hinter steckt.

Jörg Müller: Ja, genau. Das ist halt eine der Besonderheiten, im Vergleich zu vielen anderen alternativen Sprachen, die heute entstehen, dass Kotlin von Anfang mit einem sehr starken IDE Support im Hintergrund geplant worden ist. Und das merkt man der Sprache auch an, wenn man damit arbeitet. Interessant dabei übrigens, dass JetBrains, obwohl sie ja ihre eigene IDE IntelliJ haben, nicht nur IntelliJ supportet, sondern auch Eclipse. Netbeans Support existiert, glaube ich, auch. Also mindestens Eclipse Support existiert - beide natürlich nicht ganz so weit entwickelt wie der IntelliJ Support, aber immerhin ist es da, und das finde ich schon nicht unwichtig.

Lucas Dohmen: Das bedeutet, man muss nicht unbedingt im JetBrains-Ökosystem drin sein, um die Sprache zu verwenden, man kann das auch mit seinem Lieblingseditor oder IDE verwenden?

Jörg Müller: Genau, das kann man machen, korrekt.

Lucas Dohmen: Du hattest eben schon erwähnt, dass es das Konzept von Nullable und Nicht-Nulllable gibt, magst du das kurz ausführen?

Jörg Müller: Das Thema, das Werte Null werden können und die berühmte Nullpointer Exception ist ein Problem im Java Umfeld, was sehr viele Sprachen zu lösen versuchen, mit dieser typischen Wrapper Klasse, dem “Optional”. Ich mache das in Kotlin anders, auf eine sehr spannende Art und Weise: Kotlin benutzt dafür sehr stark den Compiler. Das heißt, was Kotlin grundsätzlich deklariert ist: Variablen können nicht Null sein! Kotlin überprüft auch, ob irgendwo ein Wert Null sein könnte und würde das bereits zum Compile-Zeitpunkt “anmeckern”. Was man allerdings machen kann, und da sind sie wieder sehr smart, vorher im Code sagen: “Wenn dieser Wert “not Null” ist, dann arbeiten wir mit dem Wert weiter”, was dann wiederum der Compiler auch erkennt und sagt: “Okay, alles klar, du kannst jetzt hier an dieser Stelle im Code weiterarbeiten”, ohne dabei noch einmal extra casten zu müssen oder irgendwelche anderen Aufrufe zu tätigen. Man hat natürlich die Möglichkeit mit einem Fragezeichen dahinter einen Wert als Nullable zu deklarieren, dann muss man im Code darauf achten, wie man entsprechend damit umgeht. Auch da hilft einem der Compiler wieder: Man hat, was man vielleicht von Groovy kennt, die Null-safe Dereferenzier-Möglichkeit mit dem Fragezeichen-Punktoperator, den berühmten “Elvis-Operator”, was so aussieht wie die schöne Elvis-Locke. Also Fragezeichen-Doppelpunkt, was so viel heißt wie: “Nimm diesen Wert oder, wenn er Null ist, nimm den Alternativwert, der nach dem Doppelpunkt steht”. Der Umgang mit Nullwerten in Kotlin macht deutlich mehr Spaß, als in anderen Sprachen und die Nullpointer Exception sieht man dort deutlich seltener.

Lucas Dohmen: Das macht dann ja doch die Interoperabilität vielleicht netter, als eine Sprache, die erst einmal davon ausgeht, dass es Optionals gibt, wenn man jetzt mit Java eine Interop machen möchte?

Jörg Müller: Genau, wobei, wenn man mit Java Typen umgeht, dann haben diese grundsätzlich noch den “hübschen” Ausrufezeichen-Operator hinter ihrem Typen, dass heißt, das sind dann Native Types, da greifen diese Mechanismen nicht immer, aber auch das kann man entsprechend umwandeln.

Lucas Dohmen: Cool.

Jörg Müller: Dieses Thema mit den If-Abfragen und der Compilerunterstützung ist auch sehr schön im Zusammenhang mit Casts gelöst: Ich kann auf einen expliziten Cast verzichten, wenn ich vorher abfrage, ob eine Variable von einem bestimmten Typ ist, in einer einfachen If-Clause. Dann stellt der Compiler entsprechend auch fest: “Jawoll, das ist jetzt offensichtlich dieser Typ”. Also muss da nicht noch einmal ein expliziter Cast davor stehen, sondern ich kann die Variable einfach so nutzen, als wäre sie von diesem Typ. Das, finde ich, haben sie sehr schön gelöst an dieser Stelle.

Lucas Dohmen: Du hattest eben auch kurz die Extension erwähnt, magst du kurz erklären, was das bedeutet?

Jörg Müller: Ja, was man auch schon von Groovy oder Scala kennt, ist die Möglichkeit, vorhandene Typen um weitere Funktionen zu verändern, was Kotlin auch sehr umfangreich tut mit klassischen JDK Klassen, also vor allem im Bereich von Listen oder generell Collections.

Lucas Dohmen: Was wäre da jetzt ein Beispiel, also um was wurden die erweitert?

Jörg Müller: Dinge, wie wir sie schon aus Java 1.8 kennen. Zum Beispiel ein forEach oder eine filter Funktion, eine map Funktion etc., also die typischen Higher-Level-Functions haben sie eingebaut, aber eben auch schon für ein JDK 1.6 nutzbar. Was vielleicht ganz interessant ist an der Stelle, um die manchmal damit zu erwarten Probleme zu vermeiden, haben sie eine spannende Variante zu implementieren gewählt: diese Extension Functions sind eigentlich nichts weiter als statische Methoden, die als ersten Parameter das entsprechende Objekt bekommen, sodass man sie A) auch aus Java heraus aufrufen kann – nur nicht ganz so bequem wie aus Kotlin heraus, und B) hat das eben auch zur Konsequenz, dass man bestimmte Dinge, die vielleicht auch gefährlich werden im Zusammenhang mit Extensions, nicht machen kann, wie eben zum Beispiel auf interne Werte eines entsprechenden Objektes zugreifen.

Lucas Dohmen: Also private Funktionen aufrufen, zum Beispiel.

Jörg Müller: Private Funktionen aufrufen, private Member ändern etc., das kann man eben nicht. Mag man jetzt sagen, gut, dann ist das ja eigentlich keine richtige Extension-Funktion. Ich persönlich glaube, das ist eine sehr weise Entscheidung, weil man eben eine ganze Reihe an Problemen damit umgeht.

Lucas Dohmen: Ja, das klingt auf jeden Fall sinnvoll. Das gibt einem diese grundlegende Fähigkeit von diesem “Monkey Patching”, was man aus verschiedenen dynamischen Programmiersprachen kennt, aber so ein bisschen mit “Sicherheitsgurt” sag ich mal, dass man nicht alles beliebige tun kann.

Jörg Müller: Genau, so in etwa. Wenn das ganze dann auch noch über Generics gelöst wird, was ja an der Stelle getan wird, dann ist es auch sehr mächtig. Man kann mit ein oder zwei kurzen Funktionen quasi sehr viele Objekte gleichzeitig erweitern und sehr mächtige Funktionen hinzufügen, die dann wiederum von der Tool-Unterstützung auch erkannt werden und gleich in der Code completion etc. mit angezeigt werden - etwas, was man auch nicht unbedingt von jeder Sprache so kennt.

Lucas Dohmen: Und man schreibt dann eine Extension pro Klasse oder schreibt man die für eine Instanz? Kann man nicht auch eine einzelne Objekt-Instanz erweitern oder erweitere ich immer eine ganze Klasse? Wie läuft das ab?

Jörg Müller: Du erweiterst normalerweise Klassen beziehungsweise Typen, das können dann auch generische Typen sein. Du erweiterst nicht einzelne Instanzen, nein.

Lucas Dohmen: Okay. Ich hatte auch gehört, dass Kotlin sehr gut ist mit DSLs und das es da auch nette Verwendungen von gibt. Was macht es da so attraktiv?

Jörg Müller: Kotlin hat eine ganze Reihe von Features, die, glaube ich, speziell dafür gedacht sind, um sehr gute und leichte DSLs zu schreiben, die dann trotzdem noch statisch Tool-unterstützt sind. Das kann es in der Tat ganz gut, da gibt es so einige Dinge, wie die sogenannte “Receiver Class”. Das geht ein bisschen in die Richtung der Extensions, die ich gerade angesprochen habe, und man kann also ein Objekt einer Methode übergeben und dann werden alle Aufrufe, die im Quelltext drin stehen, quasi auf dieses Objekt angewendet. Das ist schwierig auf Audio-Ebene zu beschreiben, ich kann nur empfehlen, sich das einfach mal anzugucken. Es führt dann beispielsweise dazu, dass man eine “Apply-Methode” hat, die man auf ein Objekt anwenden kann, wo dann sämtliche Aufrufe, die da drinnen stehen, am Ende nur auf dieses Objekt angewendet werden, ohne dass ich das jedes Mal wiederholen muss und mir dadurch sehr viel Boilerplate sparen kann.

Ich habe Dinge, wie “Operator-Overloading”, allerdings nur für vorab definierte Operator. Also, ich kann keine eigenen Operator erfinden. Dabei kann ich auch Infix Operatoren verwenden: 2 + 2, das Plus dazwischen als Infix kann ich ersetzen. All diese Dinge geben mir sehr viele Werkzeuge an die Hand, um eine eigene DSL zu schreiben. Wenn man das ganze dann auch noch mit Generics kombiniert, dann bekommt man eine ähnliche Leistungsfähigkeit, wie man sie vielleicht von den Groovy Buildern her kennt, mit dem man XML oder HTML gestalten kann. Oder ein schönes Beispiel im Kotlin-Umfeld ist das Exposed Framework, was auch von JetBrains geschrieben worden ist. Das ist ein Framework zur Steuerung von Datenbanken, also für Datenbankabfragen etc., und da schreibt man eben einfach: “Transaction”, dann geschweifte Klammer auf, darin ein “Create” für ein Tabellenobjekt und die “Selects” etc., sehr natürlich hintereinander weg. Ich kann nur empfehlen, wer ein bisschen mit Datenbankzugriffen zu tun hat, sich das mal anzuschauen. Wirkt sehr schön und ist, glaube ich, eines der Einsatzfelder, wo ich heute sagen würde, wenn ich sowas wie eine Internal DSL gestalten oder schreiben möchte und das ganze auch gerne auf der JVM machen will, ist Kotlin, glaube ich, das Erste, wo ich hingucken würde.

Lucas Dohmen: Das klingt auf jeden Fall sehr cool. Wie ist das denn, wenn ich jetzt so ein Kotlin-Projekt bauen möchte, benutze ich da existierendes Tooling oder muss ich mir was neues angucken? Benutze ich da Make oder so etwas wie Ant…wie sieht das aus?

Jörg Müller: Also, ich weiß nicht, ob Make funktioniert, wahrscheinlich wird es da auch eine Möglichkeit geben, Ant funktioniert tatsächlich. Sie sind da sehr kompatibel mit der klassischen Build-Welt von Java: es gibt Maven Plug-Ins, es gibt sehr gute Gradle Plug-Ins, es gibt auch Plug-Ins für Ant. Das heißt, ich kann, wenn ich ein Kotlin-Projekt bauen möchte, mich sehr in meine vorhandene Java-Umgebung einfügen. Es gibt auch zumindest ein Kotlin-inspiriertes, oder Gradle-inspriertes Build-Tool auf Kotlin-Basis, das nennt sich Kobalt. Ich weiß nicht, wie verbreitet das tatsächlich ist, denn in den meisten Fällen, wo ich Kotlin Builds sehe, sind sie eher in Gradle oder Maven. Gradle ist interessanter Weise auch hingegangen und hat die DSL Features von Kotlin benutzt, um eine eigene Gradle DSL in Kotlin zu schreiben anstelle der Groovy DSL, die Gradle normalerweise benutzt - ein spannendes Projekt, ist, glaube ich, inzwischen relativ weit fortgeschritten. Wir werden sehen ob es möglicherweise das klassische Groovy-Gradle ablösen wird, denn immerhin hat es den Vorteil statisch, typsicher und mit entsprechender Tool-Unterstützung zu funktionieren, was sicherlich ein Benefit für die Gradle-Welt ist.

Lucas Dohmen: Aber das bedeutet, ich könnte auch ein reines Java -Projekt, wenn ich das möchte, mit der Kotlin-Gradle-Sprache benutzen und könnte mein Projekt bauen, wenn ich das als einfachen Einstieg mal ausprobieren möchte?

Jörg Müller: Ja, ich glaube diese Build-Landschaft, die sehr ähnlich ist, fördert ein Einführen von Kotlin in ein Projekt, in dem man einfach sagen kann: “Ich packe da mal ein oder zwei Klassen oder Files rein, die in Kotlin geschrieben sind und interagiere mit der schönen Interoperabilität einfach in meinem Java-Code und fange damit langsam an, in meinem Projekt auf Kotlin umzustellen.” Apple macht das mit Objective-C und Swift sehr ähnlich, was ich gesehen habe, und ich glaube, dass das auch hier ein sehr guter Weg ist, um zum Beispiel in eine Migration in Richtung Kotlin reinzugehen.

Lucas Dohmen: Okay, das heißt also, so ein “Mischprojekt” ist etwas ganz Übliches und das funktioniert auch schon für umfangreichere und nicht nur für Spielprojekte, sondern, wenn ich jetzt eine gewachsene Anwendung habe, die in Java geschrieben ist, dann hätte ich durchaus die Möglichkeit, da schrittweise die Sachen rauszuziehen und zu modernisieren in Kotlin?

Jörg Müller: Ich denke es wäre ein guter Ansatz - dass es in jedem großen Java-Projekt problemlos funktioniert, möchte ich hier jetzt nicht so behaupten.

Lucas Dohmen: Okay, vielleicht eines, das vorher schon relativ problemlos gebaut werden konnte.

Jörg Müller: Ja, ich denke, das sollte nicht allzu schwer sein, das zu tun, genau.

Lucas Dohmen: Okay, also wie muss ich mir das Ökosystem vorstellen? Es ist ja eine relativ neue Sprache, wie sieht das Ökosystem aus, bekomme ich da alles, was ich brauche, oder fehlen da viele Sachen? Wie funktioniert das so?

Jörg Müller: Der eine spannende Aspekt, den man immer wieder vorne wegstellen muss, ist der, dass man die Möglichkeit hat, Java-Frameworks zu benutzen. Was wir zum Beispiel auch noch nicht erwähnt haben, ist, wenn es um Collections geht, benutzt Kotlin auch die ganz normalen Java Collections im Gegensatz zum Beispiel zu Scala. Etwas, das vielleicht Nachteile in der Performance bei funktionaler Programmierung ist, aber gleichzeitig den Vorteil hat, dass ich nichts konvertieren muss, wenn ich eine Java-Bibliothek nutzen will. Das heißt, grundsätzlich kann ich mit Kotlin sofort loslegen, weil ich alles benutzen kann, was ich aus der Java-Welt kenne.

Es gibt natürlich eine ganze Reihe von neuen Dingen, die da jetzt gerade entstehen. Sehr viel entsteht im Android-Umfeld – dadurch, dass das im Moment der größte Markt ist. Aber es gibt auch viele andere Dinge, zum Beispiel Web Frameworks, die Kotlin-eigen enstehen, die auch die DSL Features benutzen: Da wäre “Ktor”, was JetBrains mitentwickelt hat, oder http4k, was wiederum nur ein Wrapper über eine ganze Reihe von etablierten Java-Frameworks und ein Ansatz ist, den man in der Kotlin-Welt sehr häufig sieht. Das heißt, da wird kein eigener HTTP-Server entwickelt, sondern ein Jetty oder Netty oder Vert.x benutzt, oftmals auch noch konfigurierbar. Oben drüber wird dann die Syntax gesetzt, die das ganze zu typischem Kotlin macht. Der Support von Spring ist inzwischen auch recht umfangreich für Kotlin in Spring 5 oder auch in Spring Boot. Man kann zum Beispiel ganz normal auf die Spring Boot-Starterseite gehen und statt Java, Kotlin als Sprache auswählen und bekommt ein Kotlin-Spring Boot Projekt gebootstrapt. Auch in der Richtung tut sich sehr viel.

Ein weiteres interessantes Framework, worüber ich letztens einen Podcast “Talking Kotlin” gehört habe - kann man nur empfehlen, wer sich da mit dem Thema mehr beschäftigen will – die haben dort das Thema TornadoFX besprochen. Die Leute, die Java für den Desktop entwickeln möchten, für die bietet sich heutzutage JavaFX an. Swing ist, glaube ich, nicht mehr so populär. Für dieses JavaFX hat TornadoFX einen sehr schönen Wrapper geschrieben, der es deutlich leichter nutzbar macht, und, ich vermute, auch sehr gut und produktiv Desktop-Applikationen erstellen kann. Eigene Erfahrungen habe ich damit nicht, aber ich kann die Beschäftigung damit auch empfehlen.

Lucas Dohmen: Also das bedeutet auch, die Akzeptanz von Kotlin ist ziemlich groß, wenn jetzt ein relativ großes Framework wie Spring da schon Support anbietet. Da scheint ja die Community offen für zu sein.

Jörg Müller: Ja, ich denke, im Android-Bereich steht es völlig außer Frage, dass es Kotlin eine ganze Weile weiter geben wird, weil es da nicht wirklich viele Alternativen zu Kotlin gibt. Im Bereich der Java-Backend-Entwicklung hoffe ich, ehrlich gesagt, dass dort noch etwas mehr passieren wird. Ich finde die ersten Ansätze und den Support durch das Spring Framework sehr gut an der Stelle, glaube aber, dass Kotlin dort noch deutlich mehr benutzt werden könnte.

Lucas Dohmen: Wenn jetzt die Zuhörer ein existierendes Java-Projekt haben, würdest du denen ans Herz legen, sich Kotlin mal anzuschauen oder welche Rahmenbedingungen müssten da stimmen, damit du das empfehlen würdest? Wo siehst du da den Use Case? Oder den optimalen Case?

Jörg Müller: Anschauen schadet auf jeden Fall gar nicht. Ich denke Kotlin ist besser als andere Alternativen, die wir bisher auf der JVM kennengelernt haben, dazu geeignet, in einer Umgebung mit Entwicklern, die vielleicht bisher nur Java gemacht und den Schritt noch nicht gewagt haben, eine neue Programmiersprache in einer solchen Umgebung zu nutzen, weil die Einarbeitung recht leicht ist - die Sprache ist deutlich weniger komplex als zum Beispiel Scala. Die Tool-Unterstützung ist hervorragend, das heißt, man kann mit den gewohnten Tools und Libraries arbeiten. Wenn man vor der Wahl steht, in einer Java Infrastruktur einfach mal eine alternative Programmiersprache zu nehmen oder auszuprobieren, ob diese besser geeignet ist oder einen effektiver entwickeln lässt, dann ist Kotlin im Moment, glaube ich, die beste Wahl. Spätestens wenn man Use Cases hat, in denen man tatsächlich interne DSLs benutzen wollte, also irgendwelche Regel-Engines, die man implementieren möchte, und wo man etwas vorhandenes verwenden kann, würde ich einem auf jeden Fall ans Herz legen, sich mit Kotlin zu beschäftigen.

Lucas Dohmen: Klingt vielseitig, kann man also an vielen Stellen verwenden. Wenn sich jetzt die Zuhörer mehr dafür interessieren, welche Literatur oder Webseiten würdest du ihnen ans Herz legen, die man sich da mal anschauen sollte?

Jörg Müller: Also, es gibt eine Reihe an Büchern zum Thema Kotlin. Ich persönlich kann “Kotlin in Action” sehr empfehlen, das ist sehr gut geschrieben und auf dem aktuellen Stand. Man kann sich natürlich die Website selber anschauen, das ist “kotlinlang.org”. Dort hat man auch die wunderbare Möglichkeit, Kotlin direkt live auszuprobieren. JetBrains hat dort auch eine gute Web IDE installiert, die ich mir manchmal auch so wünschen würde, ehrlich gesagt. Eine sehr schöne Seite, um einen Überblick zu bekommen, welche Frameworks und weitere Ressourcen eigentlich existieren, ist “kotlin.link”. Dort gibt es auch eine wunderbare Übersicht darüber, welche Libraries existieren und was man wo einsetzen kann etc.

Lucas Dohmen: Cool, dann danke ich dir für diesen Überblick über die Sprache. Vielleicht laden wir dich noch einmal zu einem anderen Thema ein, zum Beispiel aus dem DevOps Bereich. Ich sage schon einmal vielen Dank und den Zuhörern bis zum nächsten Mal. Auf Wiedersehen.

Jörg Müller: Auf Wiedersehen.