[java] Better Lombok support

[oowekyala]

Related issues/PRs:

• [java] LocalVariableCouldBeFinal false-positive with lombok.val #5079
• [java] UnusedPrivateMethod false positives with lombok.val #5369
• Fix #5369: [java] Consider that lombok.val and var are inferred #5554
• Fix #5079: [java] LocalVariableCouldBeFinal false-positive with lombok.val #5600
• [java] InvalidLogMessageFormat: Lombok @Slf4j annotation is not interpreted by PMD #5702
  • Fix #5702: [java] First-class support for lombok @Slf4j  #5699
• [java] InvalidLogMessageFormat: false positive with lombok @Value generated methods #5787
• Support @Data, @EqualsAndHashCode (https://projectlombok.org/features/EqualsAndHashCode)
  • see [java] Fix #6096: Detect Lombok generated equals/hashCode in Comparable #6238

---

Many rules have some form of "lombok awareness", in that they ignore some constructs if they have lombok annotations. But PMD does not really handle the desugaring that lombok performs in a way, that all rules can benefit transparently.

The main issues are:

• lombok.val should be treated like the var keyword of java 10. [java] UnusedPrivateMethod false positive when passing in lombok.val as argument #3118, [java] UseDiamondOperator false positive with var initializer #1624, [java] UseDiamondOperator false-positive with Lombok val initializer #2710

• Type resolution in PMD 7 uses the AST as a source of symbols (methods, etc) to perform eg overload resolution. Those symbols are implicit when you use lombok. (eg @Getter declares a getter method), and for now are not picked up. This means, that type resolution will be much more patchy on lombok codebases, in the current state. A nice solution, would be to generate some of the symbols that correspond to annotations (the same way we add a generated symbol for eg Enum.valueOf in enum declarations). I think fully replicating the lombok desugaring is too complicated and is a non-goal. We should only generate symbols that are usable from the source language.

  For instance, the @Synchronized annotation generates a private lock field. Generating a symbol for this field is a non-goal, because it's an internal detail. It cannot mess up type resolution as it's not used in the source we're processing, only in the modified AST that lombok generates. Same thing for all annotations that just alter the AST locally, like @Cleanup.

  OTOH, @Getter is something we could care about, because some dependent code may be using the getter method. If we're not aware of this, then that dependent code will be mistyped.

I think that second item may only be implemented in PMD 7. The first item could also be implemented in pmd 6 by a motivated person.

[adangel]

Those symbols are implicit when you use lombok. (eg @Getter declares a getter method), and for now are not picked up. This means, that type resolution will be much more patchy on lombok codebases, in the current state. A nice solution, would be to generate some of the symbols that correspond to annotations

Not sure, if this is needed. When lombok is used, the produced bytecode contains the generated getter method. So we should basically pick it up via ASM, when the auxclasspath is provided. At least, it should work, when a dependent file is analyzed. If we analyze the file, which has @Getter, we have the situation, that the bytecode has more methods than we see in the source...

[oowekyala]

At least, it should work, when a dependent file is analyzed.

Yes, but the symbol implementation for those symbols that are declared in the current file exclusively rely on the AST and not the class file. Maybe we could use classpath info, but it would be hard to determine which symbols are equal and merge them, or handle inconsistencies and out-of-sync source

we have the situation, that the bytecode has more methods than we see in the source

I don't think this is a problem, as we already add synthetic method symbols for eg enums and record components

[Frederick888]

Hi, new to this project, just wondering if supporting lombok in InvalidLogMessageFormat falls into the scope of this issue?

For example, pmd reports 'missing arguments' on

public class Book {
    private static final Logger LOGGER = LoggerFactory.getLogger(Book.class);

    public void logMe() {
        LOGGER.info("Hello, %s!");
    }
}

...but not on

@Slf4j
public class Book {
    public void logMe() {
        log.info("Hello, %s!");
    }
}

Thanks :)