Lombok: [FEATURE] Provide guarded logger annotation

Created on 8 Feb 2021  路  2Comments  路  Source: projectlombok/lombok

Provide guarded logger annotation or attribute to the existing @Log4j @Log4j2(guarded = true)

The effect should be that every log.info/debug() invocation should be replaced by respective

if (log.isInfo/DebugEnabled) { log.info/debug() }

Rationale: there's a lot of enterprise code using loggers blindly and producing tons of never logged strings adding a lot of pressure to GC. Suggested approach would fix such behavior. We all know that fixing code is better just not always possible :(

Most helpful comment

In my experience, guarding is almost never necessary when loggers are used correctly:

  • Don't use Java's string concatenation. Instead, use parameterized formatting expressions to make the first parameter string static and internable by the compiler. The logging framework will automatically check the log level before concatenating strings.
  • Use lambda expressions when computing the additional parameters is expensive.

There are cases where it may be necessary, but those cases are not those one-liners which could theoretically be guarded by Lombok. So I don't think it's worth the effort (and it's not easy, because Lombok would have to know the method names for all supported logger frameworks).

Disclaimer: I'm not a Lombok team member.

All 2 comments

In my experience, guarding is almost never necessary when loggers are used correctly:

  • Don't use Java's string concatenation. Instead, use parameterized formatting expressions to make the first parameter string static and internable by the compiler. The logging framework will automatically check the log level before concatenating strings.
  • Use lambda expressions when computing the additional parameters is expensive.

There are cases where it may be necessary, but those cases are not those one-liners which could theoretically be guarded by Lombok. So I don't think it's worth the effort (and it's not easy, because Lombok would have to know the method names for all supported logger frameworks).

Disclaimer: I'm not a Lombok team member.

I've explicitly noted that we're not in a perfect world. Majority of enterprise code were written in log4j style. And unless one would love to spend rest of his life fixing broken logging proposed solution adds tremendous value

Was this page helpful?
0 / 5 - 0 ratings