Docker versus Java: Der Anfang vom Ende einer Programmiersprache?

Hartmut Schlosser
© shutterstock.com/gyn9037

Wie ist Javas Aufstieg zu erklären? Nun, zu einem guten Teil dürfte Javas Erfolg der Idee geschuldet sein, portable Anwendungen für verschiedene Betriebssysteme entwickeln zu können, ohne jedes Mal den gesamten Quellcode umschreiben zu müssen. In dieser Hinsicht bekommt Java nun Konkurrenz – allerdings nicht aus der Programmiersprachen-Welt, sondern vom Virtualisierungsprojekt Docker, dessen Container ebenfalls universell portabel sein sollen. Is Docker Eating Java’s Lunch?, fragt sich deshalb OSGi-Erfinder Peter Kriens in einem Blogpost.

Docker versus Java?

Docker soll Java Konkurrenz machen? Nicht so weit hergeholt, wenn man bedenkt, dass das „Write Once, Run Anywhere“ mit Java nicht immer zu 100% funktioniert – oft gilt es etwa, betriebssystemeigene Konventionen wie die Dateisystem-Nutzung zu berücksichtigen. Virtualisierungslösungen gehen deshalb einen Schritt weiter und liefern gleich das OS mit, das dann samt Applikation auf den jeweiligen Rechnern ausgeführt wird.

So weit, so gut. Was Docker jetzt allerdings neu macht, ist die Leichtigkeit, mit der solche Virtualisierungscontainer verwaltet werden können. Im Gegensatz zu bisherigen Lösungen ist man nicht mehr gezwungen, bei jeder kleinen Änderung System-Images in Gigabyte-Größe mitzuziehen.

Peter Kriens sieht hier eine revolutionäre Kraft am Werk, die dazu führen könnte, dass die meisten Java-Anwendungen zukünftig in Linux-Containern laufen, selbst wenn sie auf MacOS- oder Windows-Rechnern ausgeführt werden. Doch damit hätte Java sein ursprüngliches „Kaufargument“ verloren – denn für das „Write Once, Run Anywhere“ sorgt schließlich Docker. 

Was bleibt von Java?

Dann stellt sich natürlich die Frage: Was bleibt, wenn Java jeder beliebigen anderen Sprache in Sachen Portabilität nichts mehr voraus hat?

Kriens‘ Antwort: Javas Typensicherheit und Namenskonventionen sorgen dafür, dass Konflikte zwischen den Komponenten einer Anwendung vermieden werden. Zudem ermöglichen sie Navigation und Refaktorisierung innerhalb einer IDE, was unerlässlich für große Projekte ist.

Und dann wirft Kriens natürlich noch OSGi in die Waagschale: OSGi erweitere das Typensystem um private Java-Namespaces, semantische Versionierung und einem Dependency-Modell zur Laufzeit. Kein Wettbewerber könne es in dieser Hinsicht mit Java/OSGi aufnehmen, konkludiert Kriens.

Docker Bad Practices

Dennoch sträubt sich der Programmierer in Kriens gegen die neue Art der Portabilität, die durch Docker ermöglicht wird. Die Docker-Revolution sei ein Sieg für den „schlampigen“ Entwickler, schreibt Kriens. Viele schlechte Programmierweisen würden nun nicht mehr sofort bestraft – funktioniert ein Docker-Container nur irgendwie korrekt auf der eigenen Maschine, so funktioniert er überall.

Der Erfolg Dockers weist für Kriens sogar auf einen Missstand in der gesamten Software-Industrie, in der es anscheinend nur möglich war, portable Software zu liefern, wenn man diese in Bit-weise identischen Welten ausführt. Verloren gingen dabei die Elemente der Dynamik, der Anpassbarkeit, der Fehlertoleranz – verloren gingen die Best Practices, die Ingenieurs-Kunst, das Wissen um effiziente, nachhaltige Programmierung. 

There is something fundamentally wrong in our software industry if our software is so brittle and fragile that we can only make it run in a rigidly defined bitwise identical world, it points at a fundamental failure in the way we develop software. 

Schlampige Entwickler?

Nun ist Peter Kriens Argument zwar nachvollziehbar – „schlampig“ geschriebene Software profitiert durchaus von Docker. Der Schluss allerdings, dass Docker solche Bad Practices geradezu befördere, sollte nicht gezogen werden. Weder dürfte die Gefahr bestehen, dass Entwickler komplexer Software sich wegen Docker von effizienten, innovativen Architektur-Mustern entfernen. Noch werden sich die Massen von Java abwenden, weil das Thema Portabilität jetzt auch toolseitig gelöst werden kann – dafür ist die Sprache zu etabliert und heute längst nicht mehr nur aufgrund des „Write Once, Run Anywhere“-Gedankens im Einsatz.

Was wurmt Kriens also eigentlich? Nun, wenn Kriens „Java“ sagt, meint er im Grunde die Kombination „Java/OSGi“. Der ausgeklügelte Klassenlade-Mechanismus, mit dem OSGi in der Tat hocheffiziente modularisierte Software ermöglicht, wird in einer Docker-Welt sozusagen nicht thematisiert. Aus der OSGi-Perspektive ist Docker deshalb ein kruder Mechanismus, der das Portabilitätsproblem mit einem „faulen Trick“ löst.

Dass Docker aber mehr ist als ein Entwickler-Tool, kommt anscheinend nicht in den Blick. Docker muss im Kontext der DevOps- und Continuous-Delivery-Bewegung gesehen werden. Mit Docker werden Entwicklungs-, Test- und Deployment-Umgebungen leichter zu handhaben – ein großer Fortschritt für die Software-Industrie, der es so gelingt, den Graben zwischen Entwicklung und Betrieb weiter zu schließen und Software schneller – und vor allem mit deutlich weniger lästiger, fehleranfälliger Handarbeit – an den Mann zu bringen.

Klar ist auch, dass Docker keineswegs die einfache Lösung aller DevOps-Probleme darstellt. „Schlampig Entwickler“ werden auch schnell mit Docker-Infrastrukturen an ihre Grenzen stoßen. Hingegen könnte es gut sein, dass Kommentator Joerg Recht behält, der Kriens antwortet, dass Docker Entwicklern dabei hilft, ihre Entwicklungs- und Testumgebungen sauber zu managen, sodass diese sich voll auf ihre eigentliche Arbeit konzentrieren können: Das Schreiben hochqualitativer Software.

Aufmacherbild: Stack of Cargo Containers at the docks von Shutterstock / Urheberrecht: gyn9037

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: