Просмотрев топики по логированию с использование Java, я с удивлением обнаружил только один топик описывающий EDL (новая система логирования, которую предлагает автор) и всё. Поэтому ниже я хотел бы рассмотреть основные инструменты, с которыми сталкивается разработчик, решающий добавить логирование в свою систему.
Наиболее широкое распространение получили следующие библиотеки:
- Apache Log4J
- JDK Logging API
- Commons Logging API
- SLF4J
- Logback
Рассмотрим каждую более подробно и попытаемся понять, какая для чего предназначена и какие следует использовать.
Apache Log4J
Это библиотека была разработана, как видно из названия, сообществом Apache и является стандартом де-факто в мире логирования Java. Она появилась раньше всех остальных. Так первая альфа версия появилась в 1999 году, во времена Java 1.2. Версия с номером 1.0 появилась в 2001 году, то есть во времена Java 1.3. Я так много говорю о датах и версиях Java потому, что до появления Java 1.4 в 2002 году у разработчиков было всего две альтернативы: самим реализовывать систему логирования, либо использовать Log4J. Соответственно, ясно, что большинство стало использовать Log4J, и продолжают ей пользоваться. С тех пор, библиотека продолжает развиваться и поддерживаться.
Сконфигурировать Log4J можно либо с помощью XML, либо с помощью файла свойств, имеющего стандартный Java Properties синтаксис.
Она поддерживает множество способов вывода логов: консоль, файлы, GUI компоненты, сокеты, JMS, NT Event Logger, Unix Syslog, SMTP, Telnet, базы данных. Форматирование доступно в форматах: XML, обычный текстовый вывод, HTML, TTCCLayout и форматирование на основе паттерна.
Log4J используют такие проекты, как Hibernate и JBoss. Существуют реализации для C++, .NET и PHP.
JDK Logging API
JDK Logging API был создан, как результат JSR 47, и теперь включён в пакет java.util.logging (JUL). JUL очень схож с Log4J как синтаксически, так и логически, но предоставляет меньше возможностей. Разницу в функциональности можно описать следующей фразой: «Всё что умеет делать JUL, Apache Log4J тоже умеет, а также умеет многое другое».
Так JUL предоставляет возможность вывода логов в файл, консоль, сокет и буффер и форматирование в виде xml и обычного текстового вывода. Это всё. Настройка JUL возможна только с помощью файла свойств (Java properties).
Commons Logging API
Commons Logging API ещё один API о котором можно часто услышать при разговоре о логировании в Java. На самом деле Commons Logging API (JCL) является всего лишь обёрткой над различными логирующими системами. В настоящий момент поддерживаются вышеописанные Apache Log4J, JUL и Avalon LogKit. Причём в большинстве случаев, JCL является обёрткой над Log4J и возможность безболезненно перейти на JUL не используется. Таким образом JCL лишь утяжеляет систему логирования, уменьшает её производительность (из-за через мерного использования механизма reflection), приводит к утечкам памяти и приводит возможности логирования к наименьшему общему делителю, то есть к JUL.
Таким образом, очень часто использование JCL абсолютно не оправданно, создаёт больше проблем, чем решает. Почему же JCL используется во многих библиотеках и проекта? Причина в том, что существует множество проектов, которые уже используют JCL и для совместимости с ними приходится пользоваться JCL.
Вот высказывание автора JCL Rod Waldhoff о своей библиотеке:
SLF4J
К счастью, существует другая обёртка над множеством логирующих систем, которая лишена недостатков JCL — это SLF4J. SLF4J это акроним от Simple Logging Facade for Java. В нём реализована поддержка MDC (), есть поддержка параметризованных сообщений, которые позволяют сократить время, затрачиваемое на построение аргумента для лога, при отключенном логировании.
SLF4J представляется собой набор модулей, ответственных за «переброс» логов от одной системы к другой. В ней нет никакого динамического связывания и никакой магии classloader'ов, как в JCL. Так, например, чтобы настроить передачу JUL логов в Log4J достаточно положить в CLASSPATH 3 *.jar файла: jul-to-slf4j-*.jar, slf4j-api-*.jar,slf4j-log4j12-*.jar.
SLF4J поддерживает в настоящий момент JCL, JUL, Log4J и Logback.
Её используют многие проекты, включая, Apache Geronimo, LIFERAY, Sonar, Spring Dynamic Modules for OSGi, Hibernate и многие другие.
Logback
Logback проект, созданный Ceki Gülcü — человеком, который создал Log4J. Logback концептуально очень похож на Log4J и JUL. Он является развитием Log4J и отличается от него тем, что обладает более высокой производительностью, может быть сконфигурирован с помощью XML и Groovy, поддерживает автоматическую загрузку конфигурационных файлов, автоматическую поддержку архивирования, новые фильтры и многое другое.
Logback является «нативной» реализацией SLF4J API, то есть, если Вы используете Logback, Вы используете SLF4J API. Таким образом, при логировании с помощью SLF4J и Logback Вы не теряете в производительности из-за обёртки.
Выводы
Так что же стоит использовать в новых проектах? Какие системы наиболее оптимальны? Что выбрать, если такая возможность существует?
Большинство разработчиков (я в том числе), считают, что сейчас вариант SLF4J + Logback является наиболее оптимальным. Logback обладает всеми преимуществами Log4J и тем более JUL, при этом превосходя их по многим параметрам. А использование SLF4J всегда позволит переключится на другую логирующую систему безболезненно и при этом не обладает минусами JCL.
Из вышеуказанного совета есть одно исключение. Если Ваш проект крайне простой и не предполагает сложной и гибкой системы логирования, то разумно использовать JUL. При этом Вам не придётся тянуть за собой другие библиотеки, можно будет ограничиться стандартным JDK.