Blog

EJAPP Top 10 Countdown: #4 - Schlecht performende Bibliotheken

Vincent Partington

Aktualisiert Oktober 23, 2025

3 Minuten

Nachdem ich das Osterwochenende ausgelassen habe, um in Chamonix Snowboard zu fahren, setze ich den EJAPP Top 10 Countdown mit Nummer 4 fort. Schlecht funktionierende Bibliotheken sind ein Problem, das häufiger auftritt, als man erwarten würde. Dieses Problem ähnelt in gewisser Weise der falschen Verwendung von Java EE, da bei der Auswahl und Verwendung einer bestimmten Technologie nicht sorgfältig genug vorgegangen wird. Einige Entwicklungsteams stapeln fröhlich JAR um JAR in ihr WEB-INF/lib-Verzeichnis oder in ihre POM-Datei, :

ohne zu prüfen, ob diese Bibliothek wirklich benötigt wird (und sich nicht mit Funktionen überschneidet, die bereits von anderen verwendeten Bibliotheken angeboten werden),
ohne zu prüfen, ob diese Bibliothek eine gute Leistung bieten kann oder ob eine leistungsfähigere Alternative verfügbar ist,
ohne die Dokumentation zu lesen, um zu sehen, wie es richtig verwendet werden sollte, und
ohne zu definieren, wie die Bibliothek in der Anwendung verwendet werden soll

Beispiele hierfür sind:

BEAs Implementierung der STaX-API, die mehr als zweimal langsamer ist als die einiger Konkurrenten.
java.net.URLEncoder, der bis zu 90 Mal (!) besser ist als org.apache.commons.codec.net.URLCodec in Multi-Thread-Anwendungen (= alle Webanwendungen).
Frühere Versionen von JAMon hatten eine schlechte Leistung aufgrund der wiederholten Zuweisungen von DateFormat und NumberFormat. Ironischerweise ist JAMon ein Tool zur Überwachung der Leistung Ihrer Anwendung ;-)

Noch schlimmer ist, dass einige Entwicklerteams ihre eigenen Frameworks und Bibliotheken schreiben, wo es bereits welche gibt, die (fast) die gleiche Funktionalität und (in der Regel) eine bessere Leistung bieten. Abgesehen von der anfänglich schlechteren Leistung entwickeln sich diese Bibliotheken und Frameworks in Bezug auf Leistung (und Funktionalität und Sicherheit und ...) nicht so schnell weiter wie bestehende (freie) Bibliotheken. Wie Linus sagt: Viele Augen machen alle Fehler seicht. Leider kann ich hier keine Beispiele nennen, da diese Frameworks per Definition proprietär sind. Um diese Art von Problemen zu vermeiden, sollten Sie auf jeden Fall die folgenden Schritte befolgen, wenn Sie eine bestimmte Funktionalität benötigen:

Überprüfen Sie die bereits im Projekt verwendeten Bibliotheken auf ihre Funktionalität.
Prüfen Sie vorhandene (kostenlose) Bibliotheken auf die Funktionalität.
Nur wenn keine vorhandene Bibliothek gefunden werden kann, implementieren Sie die Funktionalität selbst. Ziehen Sie in Erwägung, sie als freie Software zu veröffentlichen. Die Gemeinschaft wird davon profitieren und vielleicht sogar zusätzliche Funktionen, Leistungsverbesserungen, Sicherheitskorrekturen usw. anbieten.
Vergewissern Sie sich, dass die ausgewählte Bibliothek die erforderliche Leistung erbringen kann.
Lesen Sie die Dokumentation, Newsgroups und Foren über die richtige Verwendung der Bibliothek.

Und erst dann verwenden Sie eine vorhandene Bibliothek oder erstellen Ihre eigene.