Ein großartiger Java-Rant von Kris Köhntopp

#1

Das ist auch sprachlich ein solches Meisterwerk, dass ich es euch nicht vorenthalten will:

Das ist so, weil in Java nichts jemals simpel ist. Java Code ist unstrukturierter trockener Staub von Codefragmenten in Klassendateien, die inert in keiner Weise miteinander interagieren. Erst mit den passenden Factories, Delegates, Generators und ClassLoaders werden sie instanziiert und zusammengesetzt. Der entstehende Haufen an Querverweisen führt dann nur zufällig irgendwann einmal tatsächlich wirksamen Code aus.

:crazy_face:

Drauf aufmerksam wurde ich bei Fefe, der noch ergänzt:

Besonders witzig bei Kris’ Ausführungen finde ich, dass er für seine jahrzehntelage Arbeit in der PHP-Community bekannt ist, und dieses verkackte Classloader-Konzept, zur Laufzeit Code nachladen zu wollen, ist auch eine glorreiche PHP-Innovation, die dort allerdings Autoloader heißt.
Dass das möglicherweise grundsätzlich eine völlig verkackte Idee ist, zur Laufzeit Code nachzuladen, ist nicht nur den Founding Fathers von Java nicht gekommen.
Auch in C und C++ gibt es ein API, mit dem man Shared Library nachladen kann, heißt dlopen oder LoadLibrary, und wird für Plugins verwendet. Und auch da haben viele Leute noch nicht verstanden, dass das Plugin dann dieselben Zugriffsrechte hat wie das Programm, in dessen Kontext es ausgeführt wird.

#2

Ah, dazu passt auch dieser Aufruf von Fefe:

Liebe Leser, ich bereite gerade einen Vortrag vor, in dem es darum gehen soll, wie verkrustet die Softwareentwicklung ist.
Daher wollte ich jetzt mal eine Umfrage machen und bitte um Zusendung von Daten für eine Statistik. Selbstverständlich wird das nur als aggregierte Übersicht veröffentlicht.

Dann folgt eine Liste von 17 Punkten, die ihn interessieren. Das Ergebnis davon interessiert mich dann auch. :upside_down_face:

#3

Da muss ich mich als Java Entwickler klar zu Wort melden ,-)
Eine recht einfache Sicht auf die Problematik! Und keineswegs ein Java Problem!
Ich sehe viele Argumente auf Java Projekte anwendbar, aber das hat nix mit Java zu tun.
Ich kann mit Java auch einen Monolithen bauen, der nur System.in, System.out und System.err nutzt. Aber dann hab ich evtl. an den Anforderungen vorbei implementiert.

Logging und Konfiguration ist in der heutigen Zeit eben nicht mehr das was es mal war.
Wobei ich es bevorzuge auf System.out zu loggen und die Laufzeitumgebung dass dann zur Analyse weiterleitet oder aufbereitet.

Die Konfiguration in die Codebase zu packen ist auch etwas kurz gedacht. Denn dann ist die Codebase abhängig von der Laufzeitumgebung.

Libs wie Log4j vereinfachen das Leben des Entwicklers. zusammen mit lombock annotiert man eine Klasse eben nur noch und verwendet dann log.info(…), log.debug(…), …
Und was dann zur Laufzeit passiert wird konfiguriert. Wobei das oft statisch und beim compile schon passiert!
Das nennt man Separation of concerns

Ich sehe eher eine Problematik bei Dependency Management Tools wie Maven. Denn da wird wirklich ne ganze Menge Zeugs geladen. Das ist zwar bequem, aber Überblick kann man da kaum haben. Mein naives Verständnis von npm lässt mich aber vermuten, dass es da nicht soviel unterschied gibt.