Environment
redhat.java: 1.54.0
- Lombok version: 1.18.46
- Java version: 25
Lombok configuration
lombok.config
# Generate fluent-style accessors, e.g. "name()" instead of "getName()",
# and "name(value)" instead of "setName(value)".
lombok.accessors.fluent = true
# Make generated setter-like methods return "this" so calls can be chained,
# e.g. "obj.name(value).age(42)".
lombok.accessors.chain = true
Reproduction
In the demo project:
demo.zip
- Open
Car.java
- Locate the
engine field
- Run Find All References on
engine
Actual behavior
VS Code / JDT LS reports:
No references found
However, the field is referenced from DemoApplication.java via:
Additionally:
- Navigating from
car.engine() in DemoApplication.java
- Using Go to Definition / Peek Definition
points to a Lombok-generated @Getter method instead of resolving to the backing engine field.
Expected behavior
Find All References on the engine field should include usages through Lombok fluent accessors such as:
- Go to Definition from
car.engine() should resolve to the engine field (or the generated fluent accessor associated with that field), not the unrelated Lombok @Builder method.
Notes
The issue appears specifically related to:
lombok.accessors.fluent = true
lombok.accessors.chain = true
Standard JavaBean-style getters/setters do not appear to exhibit this behavior.
Environment
redhat.java: 1.54.0Lombok configuration
lombok.configReproduction
In the demo project:
demo.zip
Car.javaenginefieldengineActual behavior
VS Code / JDT LS reports:
However, the field is referenced from
DemoApplication.javavia:Additionally:
car.engine()inDemoApplication.javapoints to a Lombok-generated
@Gettermethod instead of resolving to the backingenginefield.Expected behavior
Find All Referenceson theenginefield should include usages through Lombok fluent accessors such as:car.engine()should resolve to theenginefield (or the generated fluent accessor associated with that field), not the unrelated Lombok@Buildermethod.Notes
The issue appears specifically related to:
Standard JavaBean-style getters/setters do not appear to exhibit this behavior.