阅读中文版本

Lombok Annotations Not Processed — Getters Missing

Fix "cannot find symbol getX" with Lombok by enabling annotation processing, aligning Lombok with the JDK, and reordering the compiler plugin.

mvn -q clean compile 2>&1 | grep "cannot find symbol" | head

mvn dependency:tree -Dincludes=org.projectlombok:lombok && java -version

Symptoms

The error “Lombok Annotations Not Processed — Getters Missing” points at a specific failure mode. This guide documents the symptoms you can observe, the commands that isolate the cause, the root cause, the fix, and the checks that prove the fix works.

Observed symptoms include:

• Compilation fails with “cannot find symbol: method getName()” though @Data is present
• The IDE shows no error but the command-line build fails
• Breakage started after a JDK upgrade

Reproduce and Diagnose

Reproduce the failure in isolation before changing any code. Work through the checks below in order; each one narrows the search space.

Step 1: Confirm the generated member is truly missing

mvn -q clean compile 2>&1 | grep "cannot find symbol" | head

The missing getter proves the processor did not run, not that the annotation was ignored.

Step 2: Check Lombok and JDK versions

mvn dependency:tree -Dincludes=org.projectlombok:lombok && java -version

Lombok must be recent enough for the JDK; old Lombok fails silently on new JDKs.

Likely contributors, in order of frequency:

• Annotation processing is disabled in the build tool
• The Lombok version does not support the running JDK
• Lombok is not on the annotation processor path, only on the compile classpath

Root Cause

Lombok generates code through the annotation processor. If processing is disabled or the Lombok version predates the JDK, the processor never runs, so no getters or builders are emitted and compilation cannot resolve them.

The Fix

Enable annotation processing, upgrade Lombok to a JDK-compatible release, put it on the annotationProcessor path, and ensure the compiler plugin processes annotations.

Watch out: Lombok is closely coupled to compiler internals; a JDK upgrade can break it until Lombok updates, so pin versions together.

<!-- pom.xml -->
<dependency>
  <groupId>org.projectlombok</groupId>
  <artifactId>lombok</artifactId>
  <version>1.18.32</version>
  <scope>provided</scope>
</dependency>

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.13.0</version>
  <configuration>
    <annotationProcessorPaths>
      <path>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.32</version>
      </path>
    </annotationProcessorPaths>
  </configuration>
</plugin>

Verify and Prevent

Rebuild and confirm the getter resolves; run javap on the generated class to see the synthesized methods.

Once verified, add a regression test that reproduces the original symptom so the failure cannot silently return.

This class of failure is usually environmental rather than pure logic, so capture the exact command, the environment variables, and the working directory in your bug report. Reproduce it in the smallest possible script, then widen the scope only once the minimal case is understood. A short written checklist for this failure mode saves hours the next time it appears.