Vaut-il la peine d'utiliser slf4j avec log4j2

Je ne suis pas en mesure de décider d'utiliser ou non slf4j avec log4j2. Sur la base des publications en ligne, il ne semble pas que les performances soient affectées, mais est-ce vraiment nécessaire.

Aussi ces points régissent en faveur de log4j2:

• SLF4J force votre application à consigner les chaînes. L'API Log4j 2 prend en charge la journalisation de toute CharSequence si vous souhaitez enregistrer du texte, mais prend également en charge la journalisation de tout objet tel quel.
• L'API Log4j 2 prend en charge la journalisation des objets Message, les expressions lambda Java 8 et la journalisation sans garbage (elle évite de créer des tableaux vararg et évite de créer des chaînes lors de la journalisation des objets CharSequence).

Allez-y: programmez vers l'API log4j2 au lieu de slf4j

C'est sûr: l'API Log4j2 offre exactement les mêmes garanties que slf4j - et plus encore.

Maintenant que Log4j2 lui-même est séparé en une API et un module d'implémentation, il n'y a plus aucune valeur à utiliser SLF4J.

Oui, il est bon de garder vos options ouvertes. Vous souhaiterez peut-être passer à une autre implémentation de journalisation ultérieurement.

Au cours des 10 dernières années environ, créer une telle flexibilité dans votre application signifiait utiliser une API wrapper comme SLF4J. Cette flexibilité n'est cependant pas gratuite: l'inconvénient de cette approche est que votre application ne peut pas utiliser l'ensemble de fonctionnalités plus riche de la bibliothèque de journalisation sous-jacente.

Log4j2 offre une solution qui n'exige pas que votre application soit limitée au plus petit dénominateur commun.

La valve d'échappement: log4j-to-slf4j

Log4j2 comprend un log4j-to-slf4jmodule de pont. Toute application codée par rapport à l'API Log4j2 peut choisir de basculer à tout moment l'implémentation de support vers n'importe quelle implémentation conforme à slf4j.

Comme mentionné dans la question, l'utilisation de l'API Log4j2 offre directement plus de fonctionnalités et présente des avantages non fonctionnels par rapport à l'utilisation d'une API wrapper telle que slf4j:

• API de message
• Lambdas pour la journalisation différée
• Enregistrer n'importe quel objet au lieu de seulement des chaînes
• Sans garbage: évitez de créer des varargs ou de créer des chaînes lorsque cela est possible
• CloseableThreadContext supprime automatiquement les éléments du MDC lorsque vous en avez terminé

(Voir 10 fonctionnalités de l'API Log4j2 non disponibles dans SLF4J pour plus de détails.)

Les applications peuvent utiliser en toute sécurité ces riches fonctionnalités de l'API Log4j2 sans être verrouillées dans l'implémentation principale native de Log4j2.

SLF4J est toujours votre soupape de sécurité, cela ne signifie tout simplement pas que votre application doit plus coder avec l'API SLF4J.

Divulgation: je contribue à Log4j2.

Mise à jour: Il semble y avoir une certaine confusion que la programmation de l'API Log4j2 introduit en quelque sorte une "façade pour une façade". Il n'y a aucune différence à cet égard entre l'API Log4j2 et SLF4J.

Les deux API nécessitent 2 dépendances lors de l'utilisation d'une implémentation native et 4 dépendances pour une implémentation non native. SLF4J et l'API Log4j2 sont identiques à cet égard. Par exemple: