Lombok and log4shell

Project lombok has become a defacto standard in close to every Java project I see. Because of this I want to also write about the ongoing log4j problems as described under https://blog.coffeebeans.at/archives/1709.

The annotation @Log4j allows to create a log4j logger field in the annotated class. This of course implicates that your project is using Log4j for logging and could make your application vulnerable to log4shell if not updated to latest release.

I would highly recommend using @Slf4j instead of @Log4j and use the Simple Logging Facade 4 Java functionality to be able to replace the logging implementation by simply changing some configs and/or libraries instead of changing your code for doing so.

Sample with @Log4j:

class SampleLog4j {

  public void soSomething() {
    log.debug("this is a log4j log message");


The same sample using slf4j:

class SampleLog4j {

  public void soSomething() {
    log.debug("this is a slf4j log message");


As you can see for simple string messages there is no difference at all. A big difference comes in place when it comes to parameterised log messages which log like the following with slf4j:

log.error("this is a {} error message", someVar, exception);

Taken from my knowledge with log4j (which was going down over the years of using slf4j already) there would be a way with ParameterizedMessage or simple String.format to achieve the same:

// with String.format
log.error(String.format("this is a %s error message", someVar), exception);

// or string concatenation
log.error("this is a " + someVar + " error message", exception);

// or with ParameterizedMessage
log.error(new ParameterizedMessage("this is a {} error message", someVar), exception);

I don’t think that ParameterizedMessage is really used a lot and most people rely on string concatenation or String.format. From that perspective: Biggest difference are the used log levels: Slf4j doesn’t know the fatal log level – see https://www.slf4j.org/faq.html#fatal. If you’re happy the do some changes on that you should be able to replace @Log4j with @Slf4j after having taken care about fatal. Of course this assumes you’re doing nothing fancy with your logger ;-) Also checkout the migrator tool: https://www.slf4j.org/migrator.html.

If you’re in a JEE environment with jboss/wildfly/eap (or simply used to it) also @JBossLog could be interesting to you which would generate a jboss-logger instance for you that would also not be vulnerable to log4shell but is also naming a logging implementation directly in your code instead of using a facade.

Checkout the lombok external logger implementations yourself under https://projectlombok.org/api/index.html.