Deaktivieren Sie die Protokollierung in Java zur Kompilierzeit

Question

Ich habe einige Java-Code, den ich mit Protokollmeldungen für Debugging-Zwecke instrumentieren möchte. Der endgültige (kompilierte) Produktionscode sollte jedoch keine Protokollierung enthalten, da dies die Ausführungszeit verlangsamen würde. Gibt es in Java eine Möglichkeit, einen Logger zur Kompilierzeit zu deaktivieren?

Ich habe keine Angst vor dem Fußabdruck eine Überprüfung in der Protokollmethode eines Laufzeit-aktivierten/deaktivierten Loggers hinzufügen würde.

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

Aber ich möchte Parameter Aufbau wie die folgende in meiner Produktionscode vermeiden:

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

Ich bin mit Suns Java-Compiler.

Answer 1

Ich kenne keine Compiler-Funktionalität zu diesem Thema, aber Sie könnten auch ein Build-Skript erstellen. Dieses Skript kopiert die ursprünglichen (Debug-) Java-Quelldateien, kopiert sie an einen temporären Speicherort, entfernt die Protokollierungsanweisungen von ihnen und kompiliert dann die neuen Quelldateien, die dann ohne Debug-Code sind.

Answer 2

Es gibt keine integrierte Möglichkeit, die dies ermöglicht. Vielleicht möchten Sie einen Java Preprocessor verwenden.

Answer 3

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

Jedes Logging-Framework ich verwendet habe, müssen Sie die oben genannten Muster verwenden unnötige Auswertung des Logging Ausdrucks zu vermeiden.

Answer 4

Eine Möglichkeit besteht darin, eine Überprüfung außerhalb der Protokollmethode durchzuführen. Fast die gleiche Prüfung wie Sie erwähnt haben, aber Sie tun es selbst:

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

Diese Methode kann mit jeder Protokollebene verwendet werden. Weitere Informationen finden Sie unter Logger#isLoggable(Level). Beachten Sie, dass dies der empfohlene Weg ist, den Aufbau von Log-Methodenparametern zu vermeiden.

Answer 5

Dies scheint zu sein, was Sie suchen:

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

Answer 6

Ein hässlicher Hack, die funktionieren könnte ist die Umsetzung der Logger-Bibliothek mit einer leeren Implementierung zu verstecken. Der Optimierer wird sie inline einfügen, und die Entfernung von Deadcode sollte die Parameterkonstruktion entfernen. Dies funktioniert nicht, wenn die Parameterkonstruktion Nebenwirkungen enthält.

Jetzt ist dies Theorie, ich habe dies in der Praxis nicht getestet. Ich bin aber neugierig darauf. Vielleicht rechtfertigt dies eine separate Frage?

Answer 7

Sie sollten wirklich eine Füllstandsanzeige für Ihre Protokollnachrichten verwenden, Level.SEVERE -> Level.FINEST.

Es gibt vordefinierte Methoden in dem Logger für diesen dh:

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

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

dies ermöglicht es Ihnen minumim Protokollierungsebene auf der Anwendungsebene und Ein-/Ausschalten diese Nachrichten unter der konfigurierten Ebene mit dem Befehl konfigurieren Zeile, Konfigurationsdateien oder manuell mit LogManager

Answer 8

Haben Sie den Ansatz von slf4j mit {} - Platzhaltern berücksichtigt. Dies ermöglicht eine verzögerte Konstruktion der toString(), was bedeutet, dass log.debug (...) billig ist, wenn die Debug-Protokollierung deaktiviert ist.

Answer 9

Ich verstehe, dass der Java-Compiler in der Lage ist, Code-Blöcke zu eliminieren, die durch einen kompilierten Zeitkonstanten-Ausdruck geschützt werden. Also in der Theorie sollten Sie in der Lage sein, dies wie folgt mit etwas zu tun:

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

public class Something 
    .... 

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

Leider müssen Sie jede Klasse neu zu kompilieren, die auf der Logging.ENABLED Flagge hängt, wenn Sie seinen Wert ändern. Also ziehe ich viel folgend:

public class Something 
    .... 

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

was den Vorteil hat, dass man feinkörnige Anpassungen die Protokollierungsstufen bei der Konfiguration oder sogar zur Laufzeit machen kann; z.B. mit einem Debugger, JMX, usw. Auch der Aufwand für den Aufruf von logger.isDebugEnabled() in Log4j ist niedrig genug, dass es unwahrscheinlich ist, dass es auffällt, wenn Sie eine wahnsinnige Menge an Logging in Ihrer Codebasis haben.

Answer 10

Es ist möglich, die Java-Klassendateien mit Proguard nachzubearbeiten und die Option -assumenosideeffects zu verwenden, um die Protokollierungsaufrufe zu entfernen. Dies geschieht am häufigsten für Android mit:

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

alle Anrufe Log.d(TAG, "message") zu entfernen, etc ...