NEW in lombok 0.10: You can annotate any class with a log annotation to let lombok generate a logger field.
The logger is named log
and the field's type depends on which logger you have selected.
There are six choices available:
@CommonsLog
private static final org.apache.commons.logging.Log log = org.apache.commons.logging.LogFactory.getLog(LogExample.class);
@Log
private static final java.util.logging.Logger log = java.util.logging.Logger.getLogger(LogExample.class.getName());
@Log4j
private static final org.apache.log4j.Logger log = org.apache.log4j.Logger.getLogger(LogExample.class);
@Log4j2
private static final org.apache.logging.log4j.Logger log = org.apache.logging.log4j.LogManager.getLogger(LogExample.class);
@Slf4j
private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(LogExample.class);
@XSlf4j
private static final org.slf4j.ext.XLogger log = org.slf4j.XLoggerFactory.getXLogger(LogExample.class);
If a field called log
already exists, a warning will be emitted and no code will be generated.
A future feature of lombok's diverse log annotations is to find calls to the logger field and, if the chosen logging framework supports
it and the log level can be compile-time determined from the log call, guard it with an if
statement. This way if
the log statement ends up being ignored, the potentially expensive calculation of the log string is avoided entirely. This does mean
that you should NOT put any side-effects in the expression that you log.