Стоит ли использовать slf4j с log4j2

Я не могу решить, использовать ли slf4j с log4j2 или нет. Судя по онлайн-сообщениям, не похоже, что это повлияет на производительность, но действительно ли это необходимо.

Также эти пункты правят в пользу log4j2:

• SLF4J заставляет ваше приложение регистрировать строки. API Log4j 2 поддерживает регистрацию любого CharSequence, если вы хотите регистрировать текст, но также поддерживает регистрацию любого объекта как есть.
• API Log4j 2 предлагает поддержку для ведения журнала объектов сообщений, лямбда-выражений Java 8 и ведения журнала без мусора (он позволяет избежать создания массивов vararg и позволяет избежать создания строк при регистрации объектов CharSequence).

Вперед: запрограммируйте API log4j2 вместо slf4j

Это безопасно: API Log4j2 предлагает те же гарантии, что и slf4j, и даже больше.

Теперь, когда сам Log4j2 разделен на API и модуль реализации, использование SLF4J больше не имеет смысла.

Да, это хорошая инженерная практика - оставлять ваши варианты открытыми. Позже вы можете захотеть перейти на другую реализацию ведения журнала.

Последние 10 лет или около того создание такой гибкости в вашем приложении означало использование API-оболочки, такого как SLF4J. Однако такая гибкость не дается бесплатно: недостатком такого подхода является то, что ваше приложение не может использовать более богатый набор функций базовой библиотеки журналирования.

Log4j2 предлагает решение, которое не требует, чтобы ваше приложение ограничивалось наименьшим общим знаменателем.

Запасной клапан: log4j-to-slf4j

Log4j2 включает log4j-to-slf4jмодуль моста. Любое приложение, написанное с использованием API Log4j2, может в любой момент переключить поддерживающую реализацию на любую slf4j-совместимую реализацию.

Как упоминалось в вопросе, использование API-интерфейса Log4j2 напрямую предлагает больше функций и имеет некоторые нефункциональные преимущества по сравнению с использованием API-оболочки, например slf4j:

• API сообщений
• Лямбды для ленивого ведения журнала
• Записывать любой объект, а не только строки
• Без мусора: избегайте создания переменных или строк, где это возможно
• CloseableThreadContext автоматически удаляет элементы из MDC, когда вы закончите с ними

(Подробнее см. 10 функций API Log4j2, недоступных в SLF4J .)

Приложения могут безопасно использовать эти богатые возможности API Log4j2 без привязки к собственной реализации ядра Log4j2.

SLF4J по-прежнему является вашим предохранительным клапаном, это просто не означает, что ваше приложение больше не должно кодировать API SLF4J.

Раскрытие информации: я участвую в Log4j2.

Обновление: похоже, есть некоторая путаница в том, что программирование API Log4j2 каким-то образом вводит «фасад для фасада». В этом отношении нет разницы между Log4j2 API и SLF4J.

Оба API требуют 2 зависимости при использовании нативной реализации и 4 зависимости для неродной реализации. SLF4J и Log4j2 API в этом отношении идентичны. Например: