Thanks for the clarification, it makes sense now. To sum up:
we are supporting the cases where the logger is explicitly declared:
public static final org.slf4j.Logger log = LoggerFactory.getLogger(LogExample.class);
log.debug("Current object: {}", object.toString()); // issue: S2629
log.debug("Current object: " + object); // issue: S2629
But not when Lombok annotations are used:
@Slf4j
class LogExample {
// Annotation "@Slf4j" will generate:
//private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(LogExample.class);
log.debug("Current object: {}", object.toString()); // No issues
log.debug("Current object: " + object); // No issues
}
As a general observation, I think you can guess that tools modifying source code (such as Lombok) are not working well with static analysis tools (relying only on source code).
In the implementation of the rule, we are not simply relying on variable names, we also use types to improve the relevance of our results. When the declaration of the variable is not in the source code, we are can not say anything. In order to support this situation, we basically have to re-implement the @Log logic on our side. As it is not trivial at all, this seems way out of the scope for now.
Hope it clarifies the situation.
Best,
Quentin