Disable logging in Java at compile time

Question

I have some Java code that I'd like to instrument with log messages for debugging purposes. The final (compiled) production code, however, should not contain any logging as it would slow down the execution time. Is there any way in Java to disable a logger at compile time?

I am not afraid of the footprint a check inside the log method of a run-time enabled/disabled logger would add.

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

But I'd like to avoid parameter construction like the following in my production code:

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

I am using Sun's Java Compiler.

Answer 1

Have you considered the slf4j approach with {}-placeholders. That allows for delayed construction of the toString() meaning that log.debug(...) is cheap if debug logging is disabled.

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

Answer 2

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

Every logging framework I've used requires you to use the above pattern to avoid unnecessary evaluation of the logging expression.

Answer 3

It is possible to post-process the java class files using Proguard and use the -assumenosideeffects option to remove the logging calls. This is done most commonly for Android using:

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

to remove all calls to Log.d(TAG, "message"), etc ...

Answer 4

There is no built-in way that makes this possible. You may want to use a Java Preprocessor.

Answer 5

One way is to do a check outside of the log method. Almost the same check as you mentioned, but you do it yourself:

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

This method can be used with any logging level. see Logger#isLoggable(Level) for more infos. Notice it is the recommanded way to avoid log method parameter construction.

Answer 6

This would seem to be what you're looking for:

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

Answer 7

I don't know about any Compiler functionality about this, but what you also could do is create a build-script. This script would copy the original (debug) Java source files, copy them to a temporary location, strip the logging statements from them and then compile the new source files which are then without debug code.

Answer 8

A ugly hack that might work is to hide the implementation of the Logger library with an empty implementation. The optimizer will inline them and deadcode removal should remove the parameter construction. This will not work when the parameter construction contains side-effects.

Now this is theory, I have not tested this in practice. I am curious about this though. Maybe this warrants a separate question?

Answer 9

You really should be using a Level indicator for your log messages, Level.SEVERE -> Level.FINEST.

There are predefined methods in the Logger for this i.e:

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

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

this will allow you to configure minumim logging level at the application level and switch on/off those messages below the configured level, using the command line, configuration files or manually using the LogManager

Answer 10

I understand that the Java compiler is able to eliminate blocks of code that are guarded by a compile time constant expression. So in theory, you should be able to do this with something like this:

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

 public class Something
     ....

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

Unfortunately, you need to recompile every class that depends on the Logging.ENABLED flag whenever you change its value. So I much prefer the following:

public class Something
     ....

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

which has the advantage that you can make fine-grained adjustments to the logging levels at configuration time or even at runtime; e.g. using a debugger, JMX, etc. Also, the overhead of calling logger.isDebugEnabled() in log4j is low enough that it is unlikely to be noticeable unless you have an insane amount of logging in your codebase.