ArticleJava-Logging-Frameworks
Wer die Wahl hat hat die Qual. Vor einigen Tagen wollte ich in einem kleineren Projekt Logging-Funktionalität einbauen und stand vor der Wahl eines Logging-Framworks. Das war ein willkommener Anlass sich einen Überblick aktueller Logging-Frameworks zu verschaffen. Das Ergebnis möchte ich natürlich nicht vorenthalten:
log4j
Das ist wohl der Klassiker schlechthin und ist wohl die am weitesten verbreitete Logging-Bibliothek. Die Portierung zu anderen Programmiersprachen zeigt auch, dass das Konzept (Logger, Level, Appender, Layout) entsprechend erfolgreich ist. Fast jedes Projekt kommt mit dieser Bibliothek in Berührung, da irgendeine beteiligte Bibliothek diese verwendet. Allerdings wird Log4j nicht mehr weiterentwickelt. Selbsternannte Nachfolger, wie Logback oder Log4J 2, argumentieren oftmals mit der Performance.
Ich denke, dass man log4j getrost auch in aktuellen Projekten einsetzen kann. Performanceunterschiede im einstelligen Nanosekundenbereich sollten in den meisten Projekte keine entscheidende Rolle spielen. Wer die Wahl hat sollte allerdings einen Blick auf Logback und SLF4J werfen.
https://logging.apache.org/log4j/1.2/
Log4j 2
Die Version 2 von log4j ist nicht API-kompatibel mit der ersten Version und ob Entwickler den Schritt zu dieser Version wagen oder zu einem anderen Framework wechseln wird sich in Zukunft zeigen. Das Projekt ist ambitioniert und die Entwicklung ist derzeit noch im Alpha-Stadium.
https://logging.apache.org/log4j/2.x/
Apache Commons Logging
JCL (da früher Jakarta Commons Logging) ist kein echtes Logging-Framework, sondern eine generalisierte Logging-Schnittstelle, die mit beliebigen anderen Logging-Frameworks zusammen arbeitet. Gerade diese Zusammenarbeit hat anscheinend große Probleme bereitet, so das JCL immer mehr an Bedeutung verloren hat. Auch die Tatsache, dass die letzte Version von 2007 ist unterstreicht den veralteten Status.
https://commons.apache.org/logging/
SLF4J
Das “Simple Logging Facade for Java” beschreibt sich selbst im Namen schon sehr gut. Es handelt sich hier ebenfalls um eine generalisierte Logging-Schnittstelle, die mit beliebigen anderen Logging-Frameworks zusammen arbeitet. Die Probleme von JCL scheinen bei SLF4J nicht zu existieren. Durch das einfache Hinzufügen von JAR-Dateien entscheidet man sich für die spezielle Implementierung. Mit dem Bridging wird die Migration von anderen Logging-Frameworks vereinfacht.
JUL
Das “java.util.logging” (JUL) ist seit Java 1.4 fester Bestandteil der Klassenbibliothek und bietet ein einfaches Logging-Framework, das sich allerdings nicht mit den Features von Log4j oder Logback messen kann. Für kleinere Projekte oder Projekte, die auf externe Bibliotheken möglichst verzichten möchten, bietet sich JUL an.
Logback
Dieses Framework ist vom gleichen Autor wie log4j und beansprucht dessen Nachfolger zu sein. Insbesondere mit dem Argument bis zu 10mal schneller zu sein und weniger Speicher zu verbrauchen wird für das Framework geworben. Logback verwendet dabei die SLF4J-Schnittstelle, so dass ein Wechsel des Logging-Frameworks generell möglich ist. Das Changelog des Projektes offenbart rege Entwicklungstätigkeit. Die Verwendung von Logback scheint derzeit die beste Wahl zu sein.
Eine schöne Einführung in die Thematik gibt das Buch Java 7 Mehr als eine Insel
Keywords
