Man muss den Dingen die eigene, stille, ungestörte Entwicklung lassen, die tief von innen kommt, und die durch nichts gedrängt oder beschleunigt werden kann. Alles ist Austragen - und dann Gebären...
Reifen wie der Baum, der seine Säfte nicht drängt und getrost in den Stürmen des Frühlings steht, ohne Angst, dass dahinter kein Sommer kommen könnte.
Er kommt doch! Aber er kommt nur zu den Geduldigen, die da sind, als ob die Ewigkeit vor ihnen läge, so sorglos still und weit....
-Rilke
Liebe Weblicaner
Bereits in den letzten beiden Ausgaben unserer Entwicklerpost gab es nach langer Durststrecke endlich wieder Positives zu berichten. Wir kommen weiterhin gut voran, auftauchende Probleme lassen sich in der Regel zügig lösen. Der Beta-Test verläuft in geordneten Bahnen, aktuell stehen wir kurz vor dem Start der Beta 2.1 mit dem Schwerpunkt HTML5-Unterstützung. Da gab es bei der Umstellung eine Reihe von Problemen, insbesondere mit dem so genannten Tyding, bei dem der HTML-Code automatisch überprüft und bereinigt wird, damit die fertige Seite auch den Validator-Test des W3C besteht.
In dieser Entwicklerpost schreibe ich über die Hintergründe zu der neuen Migrationsstrategie für weblica, die uns nach Monaten des Auf der Stelle Tretens endlich wieder auf den Pfad des Fortschritts gebracht hat. Ich bemühe mich, die technischen Details auf ein Minimum zu beschränken.
Es sind nunmehr 12 Jahre vergangen, seit wir mit der Entwicklung der ersten Version von weblica begonnen haben. Schon damals, ganz am Anfang, gab es technische Hürden, die uns fast dazu gebracht hätten, aufzugeben. Wir taten es nicht.
Als wir Anfang dieses Jahres dann einsehen mussten, dass der bisher eingeschlagene Weg für Version 4 nicht zum Ziel führt, da stand auch die Frage im Raum, ob es trotz aller gegenteiligen Bestrebungen nicht besser wäre aufzuhören. Die Stimmung im Team war auf einem absoluten Tiefpunkt angelangt. Wie so oft, ist es im Nachhinein schwierig zu sagen, wann genau die Wende zum Besseren ihren Anfang nahm. Irgendwann hat jedenfalls einer im Team während einer Skype-Telco frustriert ausgerufen: "Könnten wir wenigstens IntelliJ nutzen statt diesem Sch...önheitsfehler Eclipse!". Darauf folgte eine angeregte Diskussion über die Vorteile von IntelliJ und die Gründe, die uns daran hinderten, weblica als Eclipse-RCP mit IntelliJ weiter zu entwickeln. Heraus gekommen ist dabei jedoch nichts, und am Ende der Telco waren wir so klug als wie zuvor...
Und dann, ein paar Tage später flog mir ein Gedanke zu, ein Ideenblitz, der mich förmlich zusammen zucken liess: Ich sah plötzlich einen Weg, der mir gangbar schien, noch dazu mit der Aussicht auf die Nutzung moderner Entwurfstechniken und eben IntelliJ als topmoderner Entwicklungsumgebung. Der Schlüssel zum Ganzen: die Programmiersprache Kotlin, entwickelt von der Firma JetBrains, den Machern der IntelliJ IDE.
Nun ist eine neue Programmiersprache für bestehende Systeme normalerweise alles andere als ein brauchbares Hilfsmittel für die Migration einer so umfangreichen Codebasis wie weblica. Warum also ist Kotlin in unserem Fall tatsächlich die Antwort? JetBrains hat Kotlin bewusst so entworfen, dass sie nahtlos mit Java zusammenarbeitet: Kotlin-Code lässt sich dabei problemlos aus Java-Code heraus nutzen und das Umgekehrte gilt ebenso. Das ermöglicht uns, neue Teile in Kotklin zu schreiben und diese nahtlos in die bestehende Java Code-Basis zu integrieren sowie bestehenden Java-Code nach und nach in Kotlin Code umzuwandeln.
Die Arbeit mit Kotlin ist eine wahre Freude. Vieles, was in Java dutzende von Zeilen nötig macht, schreibt man in Kotlin in wenigen Zeilen. Die Sprache ist streng typisiert, unterstützt funktionale Aspekte und ist auf leichte Verständlichkeit und hohe Produktivität getrimmt. Die Java-Kotlin-Interoperation ist gelungen und geht leicht von der Hand. Man merkt Kotlin an, dass sie von Entwicklern stammt, die um die täglichen Herausforderungen und Fallstricke in der Entwicklung wissen.
Noch ist der Grossteil von weblica in Java geschrieben, und es bestehen noch viele Abhängigkeiten zu Eclipse. Doche diese können wir nun schrittweise reduzieren, so dass wir am Schluss eine Lösung haben werden, die frei von Eclipse ist. Diese Ablösung wird in Schritten erfolgen über mehrere Versionen erfolgen. Der Grossteil der neuen Funktionen von Version 4 ist bereits in Kotlin umgesetzt.
Im Nachhinein frage ich mich manchmal, warum wir nicht schon früher auf diese Idee gekommen sind. Aber da man sich leider meist nicht mehr an das erinnern kann, was man nicht gewusst hat, ist es mir heute tatsächlich schleierhaft, warum es so lange gedauert hat. Da sind Rilkes Worte, die den Auftakt zu dieser Entwicklerpost machen, ein schwacher Trost, wenn auch nur an sonnigen Tagen.
In diesem Sinne wünsche ich allen einen guten Start in den Sommer!
Bis zum nächsten Mal.
