Ich wurde durch einen Artikel neulich im Internet angestupst, Gedanken zu einem Thema aufzuschreiben, die schon länger in meiner hinteren klinken Gehirnwindung gären: Es geht dabei um Dependency Bloat vs. Nutzen vorhandener Infrastruktur.

Alles, was ich hier aufschreibe kann man in Verbindung zu meinen letzten Artikeln zum Thema Open Source und deren Einsatz in Unternehmen sehen - muss es aber nicht.

Es geht darum, dass in vielen Projekten unglaublich viele externe Dependencies eingesetzt werden, wo das eigentlich nicht notwendig ist. Die Verwaltung der Dependencies ist mit Werkzeugen wie Maven oder Ivy für Java oder npm für Javascript, nuget für .Net oder pip für Python in den letzten Jahren wesentlich vereinfacht worden - Allerdings führt das meiner Meinung nach auch dazu, dass viele Dependencies gedankenlos zu Projekten hinzugefügt werden, die man eigentlich nicht benötigt - würde man die potentiellen Kosten einer Eigenentwicklung gegen die Probleme beim Verschwinden der jeweiligen extenen Komponente gegeneinander abwägen. Hier kommt wieder die Verbindung zu meiner Abrechnung zu Tage: Unternehmen, die so arbeiten wirken eben nicht am OpenSource-Gedanken mit - sie nehmen einfach fertige Binaries und wenn die dann verschwinden ist das Heulen und Zähneklappern groß!

Aber das nur am Rande: Der Auslöser für diesen Aufschrieb war ein Artikel über ein JavaScript Projekt, das externe Dependencies losgeworden ist und hinterher feststellte, dass die Effekte an allen möglichen Stellen nur positiv waren: reduzierte Größe des Builds, reduzierte Buildzeit, bessere Performance,...

Und das brachte mich dazu konkret darüber nachzudenken, was eigentlich Spring(Boot) in Java macht und ob man vieles davon einfach auch mit Java Bordmitteln erreichen kann? Ich kam zu dem Schluss, dass das sehr gut geht: Es existieren in Java selbst zwei Mechanismen, durch die man auf einfache Art und Weise Dependency Injection und Inversion of Control erreichen kann, ohne irgendwelche Drittanbieterkomponenten in ein Projekt integrieren zu müssen, durch deren transiente Abhängigkeiten dann das halbe Internet zum Build dazugehört.

Diese beiden Komponenenten sind das Service Provider Interface und Bean Context.

Beide stellen letztlich Implementierungen von Service-Interfaces zur Laufzeit eines Systems zur Verfügung. Ich benutze beide in dWb+ als Basis der Anwendung und kann also auf langjährige Erfahrung mit ihnen zurückblicken.

SPI ist hervorragend für Dependency Injection geeignet, da durch das Hinzufügen oder Entfernen von Artefakten - zum Beispiel durch Modifikationen der Maven Build-Datei - einfach Implementierungen im Projekt getauscht werden können. Und ja - das geschieht jeweils vor dem Build. Aber seien wir doch ehrlich - wie viele Projekte, die Spring einsetzen ändern wirklich die XML-Dateien, die den Application-Context beschreiben nachdem das Projekt gebaut ist?

Der BeanContext bzw. die Services sind im Gegensatz dazu sehr viel dynamischer: Zur Laufzeit lassen sich hier Komponenten und Services hinzufügen und entfernen. Beans können das System nach konkreten Implementierungen von Services befragen und sich sogar mittels ServiceSelector eine auf ihre speziellen Bedürfnisse zugeschnittene Implementierungsvariante wünschen. Der gesamte Lifecycle eines Service kann überwacht werden und Beans könenn sich für Events einzelner Punkte des Lifecycle registrieren: Sie werden dann beispielsweise darüber informiert, dass ab einem bestimmten Zeitpunkt gewisse Services verfügbar wurdfen oder dass bisher verfügbare Services nicht mehr zur Verfügung stehen.

All das ohne OSGI, Spring oder sonstige Dependencies - lediglich mit Java Bordmitteln. Meiner Ansicht nach sollte man in neuen Projekten erst einmal danach Ausschau halten, was mit Bordmitteln funktioniert. Dadurch reduziert man die Abhängigkeit zu Drittanbietern drastisch und tut auch noch etwas für die Nachhaltigkeit - schließlich kostet die Übertragung des halben Internet beim Herunterladen externer Komponenten Energie und Ressourcen...

Artikel, die hierher verlinken