Introducción a SLF4J

Escribo esto porque hace poco hice unas pruebas para comparar el performance de SLF4J contra Jakarta Commons Logging.

Llevaba ya tiempo usando JCL, un framework para logging que tiene la ventaja de ser una capa de abstracción sobre otros frameworks; es decir, se puede programar usando el API de JCL y en deployment se utiliza Log4J por ejemplo para hacer realmente el trabajo de los logs, o bien usar java.util.logging sin tener que cambiar una sola línea de código (JCL auto-detecta Log4J y si no está, se usa java.util.logging). Se pueden hacer interfaces para usar otros frameworks de logging.

SLF4J (Simple Logging Framework for Java) es muy similar: es simplemente una API que en tiempo de ejecución se apoya en algún framework de logging como Log4J, java.util.logging, etc. Su arquitectura interna es distinta en la manera que usa el framework real para logging: debe tenerse en el classpath el JAR que define el API junto con una sola implementación de backend, por ejemplo para Log4J.

Para compilar código que usa el API, solamente es necesario tener el JAR del API de SLF4J en el classpath. Los jars de SLF4J para usar una librería de logging solamente son necesarios para tiempo de ejecución.

SLF4J incluso tiene un JAR muy útil que contiene clases con el mismo nombre y métodos del API de JCL, pero utilizan internamente el API de SLF4J. De este modo se puede hacer una migración gradual de JCL a SLF4J, usar frameworks que requieren JCL (como Spring, o cualquier otra librería de Jakarta Commons).

En las pruebas que hice, noté que realmente SLF4J es más rápido que JCL. Ambas pruebas fueron usando Log4J para hacer el verdadero trabajo de logging; sin embargo por alguna razón es más rápido SLF4J. La diferencia en tiempo al principio no fue mucha; sin embargo, el cambio solamente había consistido en usar   en vez de  . Muchas llamadas a debug, info, etc tenían parámetros, que yo resolvía usando  , por ejemplo así:

Es mucho más rápido y eficiente usar   que concatenar las partes del mensaje usando  . Pero SLF4J además tiene su propio soporte para este tipo de mensajes, que son bastante comunes (normalmente en un log quieres dejar información útil y muy específica para el evento que estás registrando). El soporte tiene 3 métodos distintos: uno que recibe un parámetro adicional, otro que recibe dos parámetros adicionales, y uno que recibe un arreglo de parámetros (para cuando necesitas 3 o más datos). De modo que el código queda así:

La implementación de SLF4J para crear la cadena final, sustituyendo los   por los parámetros recibidos en el método, es más rápido que el  , probablemente porque es más simple que este último debido a que no acepta por el momento formatos como  ,  ,  , etc. Sin embargo, si se compara hacer   contra  , el segundo es más rápido.

La manera en que lo probé fue haciendo 10mil llamadas a un método, luego 10mil llamadas a otro, y tomar el tiempo. La diferencia no es mucha: SLF4J termina entre 50 y 300 más rápido que JCL, ambos usando  ; sin embargo al cambiar la prueba de SLF4J para usar los  , la diferencia de tiempo sube de 100 a 600 milisegundos.

Otra ventaja de usar los   en SLF4J es que el framework primero revisa si el nivel de log solicitado (trace, debug, info, warn, o error) está activo, y solamente crea la cadena con los parámetros recibidos de ser necesario. Lo cual significa que ya no es necesario llenar el código de   para imprimir mensajes en el log, porque SLF4J lo hace internamente. Con JCL hay que revisar primero, porque la llamada posterior al log incluirá un   que no hay que llamar de forma innecesaria.

Desafortunadamente, no hay métodos que reciban parámetros adicionales cuando se va a imprimir una excepción. Espero que pronto agreguen métodos que primero reciban la excepción y después reciban parámetros para poner en el mensaje, así como una versión de SLF4J que sirva en Java 5 con varargs para no tener que crear el arreglo de objetos en nuestro código.

Anexo el código que hice para estas pruebas: