jre - ¿Hay una API de Java 1.5 varargs para slf4j todavía?
java for developers (7)
¿Qué pasa con esto?
package util;
public class Util {
public static Object[] va(Object... args) {
return args;
}
}
package foo;
import static util.Util.va;
...
logger.info("a {}, b {}, c c {}", va("A", "B", "C"));
...
Puedes usar va () en otros lugares también.
Quiero deshacerme de este lote ...
public void info(String msg);
public void info(String format, Object arg);
public void info(String format, Object arg1, Object arg2);
public void info(String format, Object[] argArray);
... y reemplazarlo con este ...
public void info(String format, Object ... args);
... para que mi sintaxis de registro no tenga que cambiar dependiendo de la cantidad de argumentos que quiera registrar. Parece que hay mucha discusión y trabajo a su alrededor, pero ¿dónde está? ¿O debería envolver la envoltura que es slf4j?
Esto finalmente se resuelve. SLF4J 1.7.0 ahora requiere JDK 1.5 y tiene métodos varargs compatibles con versiones anteriores.
Hay una solución de usar varargs con SLF4J.
Hay un proyecto de código abierto llamado Lumberjack que extiende SLF4J para proporcionar métodos de registro de varargs. La extensión es muy natural, no sientes ninguna diferencia en comparación con el uso de SLF4J (esto se debe a que Lumberjack es solo una envoltura alrededor de SLF4J, por lo que toda la funcionalidad aún es proporcionada por SLF4J).
Ejemplo de uso:
JackLogger logger = JackLoggerFactory.getLogger(LoggerFactory.getLogger(Weather.class));
logger.info("Hello {}! The current time is {}:{}:{}, and after {} hours the weather will be {}.", "Jack", 13, 30, 0, 5, "sunny");
Sitio web de leñador: https://github.com/bogdanu/lumberjack
La licencia de Leñador es la misma que la licencia de SLF4J, la licencia MIT, por lo que no hay restricciones de licencia adicionales.
Descargo de responsabilidad: Soy el autor de Leñador
La verdadera pregunta es "¿Por qué un jdk <5 debe ser soportado por esto por más tiempo"? Si tiene una versión anterior de Java, use la API anterior. Es así de simple. ¿Por qué no hacer que esto encaje mejor en el mundo java actual? Quiero decir, JDK 5 ni siquiera es compatible sin un contrato de soporte de Sun / Oracle. La compatibilidad hacia atrás es una broma en este caso.
No.
El problema sigue abierto: cómo hacerlo correctamente y al mismo tiempo mantener el 100% de compatibilidad con versiones anteriores.
Siéntase libre de ver la discusión en http://bugzilla.slf4j.org/show_bug.cgi?id=31