log4j 1.2 - own check for verbose logs?

In my code's package, I have a flag such as:

public static final boolean LOGS_VERBOSE = false;

And in worker classes (multi threaded Runnable jobs), I have code like:

if(XYConstants.LOGS_VERBOSE){
    logger.debug("some state info var 1:" + var1 + ", var 2:" + var2);

Is this a good idea? Is there any performance gain? Developers say it avoids code going to the log4j level completely, and there is hardly any overhead to check the value of the constant.

We do plan to do performance testing, but that is a month away, and I need to show code to the client (who is a developer of 14 years) this Friday. I'm wondering if this should stay or not?

We have some debugs without the boolean check too, and those are wanted in all runs as long as log4j is configured in debug level.

This code is using log4j 1.2.16.

This type of practice is common, and works well.

The Java JIT compiler will identify the LOGS_VERBOSE as being a constant, and will know that it is always false, and thus will compile-out the logging entirely.

There is a slight performance hit on any code that has not (yet) been compiled.... but, once the compile has happened, there is no hit at all.

It is relatively common to use a System property to determine whether to log...

public static final boolean LOGS_VERBOSE = Boolean.getBoolean("LOGS_VERBOSE");

This behaves in the exact same way (because JIT happens after the property is set)... but, if you start your program as:

java -DLOGS_VERBOSE=true ......

then suddenly you have the fully-featured logging.

In many cases this sort of checking can improve performance because it can eliminate expensive 'setup' for log messages

StackExchange Code Review Q#36501, answer score: 6