Dependency Bloat in Java

vorhergehende Artikel in: Java Komponenten
17.12.2022

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

Tests mit Zeiten und Uhren in Java

11.01.2023

Ich habe vor nicht allzu langer Zeit hier bereits darauf hingewiesen, dass vieles, das aktuell in riesigen Frameworks vermeintlich erfunden wurde und wird bereits (seit langem) Teil von Java SE ist.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • CI/CD mit shellcheck

    13.10.2019

    Ich habe mich entschlossen, in meinen diversen Shell-Projekten shellcheck als Mittel zur Qualitätssicherung einzusetzen.

    Weiterlesen...

Neueste Artikel

  • Linux-System SBOM visualisiert als Graph

    In meinem $dayjob kam neulich die Frage auf, ob es möglich wäre, die aktuelle Softwareinstallation eines Linux-Systems als Software Bill of Materials (SBOM) zu exportieren.

    Weiterlesen...
  • Visualisierung von Datenmodellen als gerichtete Graphen

    Ich habe - motiviert durch meine Experimente zur Visualisierung von Paketabhängigkeiten in Linux-Installationen als interaktive Graphen - versucht, relationale Datenmodelle in ähnlicher Form zu visualisieren und dazu zwei Plugins für die sQLshell geschrieben.

    Weiterlesen...
  • Carl Sagan - Christmas Lectures at the Royal Institution

    Die Royal Institution hat in ihren Schätzen gegraben und die Christmas Lectures von Carl Sagan auf Youtube nochmals veröffentlicht. Meiner Ansicht nach unbedingt lohnenswert für alle, die Englisch verstehen!

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.