Deshabilitar el registro en Java en tiempo de compilación

Question

Tengo un código de Java que me gustaría utilizar como instrumento con mensajes de registro para depuración. El código de producción final (compilado), sin embargo, no debe contener ningún registro ya que ralentizaría el tiempo de ejecución. ¿Hay alguna forma en Java para desactivar un registrador en tiempo de compilación?

No le temo a la huella una comprobación dentro del método de registro de un registrador habilitado/deshabilitado en tiempo de ejecución se sumaría.

if (logging==enabled) {// do logging} 

Pero me gustaría evitar la construcción de parámetros como la siguiente en mi código de producción:

Logger.log("undefined state" + state + " @ " + new Date()); 

estoy usando el compilador de Java del solar.

Answer 1

No conozco ninguna funcionalidad del Compilador sobre esto, pero lo que también podría hacer es crear un script de construcción. Este script copiará los archivos fuente originales (depuración) de Java, los copiará en una ubicación temporal, quitará las declaraciones de registro de ellos y luego compilará los nuevos archivos fuente que no tienen código de depuración.

Answer 2

No hay una forma incorporada que lo haga posible. Es posible que desee utilizar un Java Preprocessor.

Answer 3

if(logger.isDebugEnabled()) { 
    logger.debug(expression); 
} 

Cada marco de registro que he usado requiere que utilice el patrón de arriba para evitar la innecesaria la evaluación de la expresión de registro.

Answer 4

Una forma es hacer un control fuera del método de registro. Casi el mismo cheque como usted ha mencionado, pero lo hace usted mismo:

if (LOGGER.isLoggable(Level.DEBUG)) { 
    LOGGER.log("undefined state" + state + " @ " + new Date()); 
} 

Este método se puede utilizar con cualquier nivel de registro. ver Logger#isLoggable(Level) para más información. Observe que es la forma recomendada de evitar la construcción de parámetros del método de registro.

Answer 5

Esto parece ser lo que está buscando:

what's log4j actually doing when we turn on or off some log places?

Answer 6

un feo corte que podría funcionar es ocultar la implementación de la biblioteca Logger con una implementación vacía. El optimizador los alineará y la eliminación del código muerto eliminará la construcción del parámetro. Esto no funcionará cuando la construcción del parámetro contenga efectos secundarios.

Ahora bien, esta es la teoría, no he probado esto en la práctica. Tengo curiosidad acerca de esto sin embargo. Tal vez esto justifica una pregunta por separado?

Answer 7

Realmente debería utilizar un indicador de nivel para sus mensajes de registro, Level.SEVERE -> Level.FINEST.

Hay métodos predefinidos en el registrador de este ejemplo:

Logger.info(msg); 
Logger.finest(msg); // debug/trace message. 

Logger.log(Level.CONFIG, "config message"); 

Esto le permitirá configurar el nivel de registro minumim a nivel de aplicación y el interruptor ON/OFF esos mensajes por debajo del nivel configurado, utilizando el comando línea, archivos de configuración o manualmente usando LogManager

Answer 8

¿Ha considerado el enfoque slf4j con {} -placeholders. Eso permite la construcción demorada de toString(), lo que significa que log.debug (...) es barato si el registro de depuración está deshabilitado.

log.debug("in loop() - a={}, b={}", a, b); 

Answer 9

entiendo que el compilador Java es capaz de eliminar los bloques de código que se vigilada por una expresión constante de tiempo de compilación. Por lo tanto, en teoría, debería ser capaz de hacer esto con algo como esto:

public class Logging { 
    public static final boolean ENABLED = true; // change to false 
} 

public class Something 
    .... 

    if (Logging.ENABLED) { 
      logger.debug("hello mum"); 
    } 
} 

Por desgracia, es necesario volver a compilar todas las clases que depende de la bandera Logging.ENABLED cada vez que cambie su valor. Así que me gusta mucho más el siguiente:

public class Something 
    .... 

    if (logger.isDebugEnabled()) { 
      logger.debug("hello mum"); 
    } 
} 

que tiene la ventaja de que se pueden hacer ajustes de grano fino de los niveles de registro en tiempo de configuración o incluso en tiempo de ejecución; p.ej. utilizando un depurador, JMX, etc. Además, la sobrecarga de llamar al logger.isDebugEnabled() en log4j es lo suficientemente baja como para que no sea notable a menos que tenga una gran cantidad de inicios de sesión en su base de código.

Answer 10

Es posible el procesamiento posterior de los archivos de clase Java utilizando Proguard y utilice la opción -assumenosideeffects para eliminar las llamadas de registro. Esto se realiza con mayor frecuencia para Android usando:

-assumenosideeffects class android.util.Log { 
    public static *** d(...); 
    public static *** v(...); 
} 

para eliminar todas las llamadas a Log.d(TAG, "message"), etc ...