Skip to content

Lombok copyableAnnotations (lombok.config) no longer applied to @RequiredArgsConstructor constructors in v1.55.0 (regression vs v1.54.0) #4467

Description

@rcrdlb

Describe the bug

Since updating from redhat.java v1.54.0 to v1.55.0 (picked up via extension auto-update around 2026-07-10, alongside a VS Code update to 1.129.1), the embedded Java Language Server no longer applies lombok.config's copyableAnnotations setting when Lombok generates a constructor via @RequiredArgsConstructor.

With a lombok.config:

config.stopBubbling = true
lombok.copyableAnnotations += org.springframework.context.annotation.Lazy

and a class:

@RequiredArgsConstructor
public class FooCustomImpl implements FooCustom {
    @Lazy private final FooRepo baseRepo;
    ...
}

the generated constructor parameter is expected to carry @Lazy (this is a standard Spring pattern to break a circular bean dependency between a Spring Data repository interface and its *CustomImpl fragment, by injecting a lazy proxy).

Confirmed via bytecode inspection (javap -v Foo.class | grep -A4 RuntimeVisibleParameterAnnotations):

  • Compiling the same source file via the project's Maven build (javac) → @Lazy is present on the constructor parameter.
  • Compiling the same file standalone, in batch mode, using the extension's own bundled ECJ (org.eclipse.jdt.core.compiler.batch) + the extension's own bundled Lombok agent (lombok-1.18.39-4050.jar, extracted straight from the extension's lombok/ folder) → @Lazy is present.
  • Compiling via the running jdt.ls inside VS Code with the extension at v1.55.0 → @Lazy is missing, reproducible across multiple Java: Clean Java Language Server Workspace resets.
  • Downgrading only the extension to v1.54.0 (code --install-extension redhat.java@1.54.0 --force), same project, same lombok.config, same steps → @Lazy is present again.

Also tried disabling the built-in Lombok support and pointing java.jdt.ls.vmargs at an explicit -javaagent:.../lombok-1.18.46.jar (project's own Lombok version) with java.jdt.ls.lombokSupport.enabled: false — same failure on v1.55.0, which rules out the specific Lombok jar/version as the cause and points at v1.55.0's jdt.ls integration itself.

Impact

Spring Boot fails to start with:

APPLICATION FAILED TO START
The dependencies of some of the beans in the application context form a cycle: ...

only when the app is run/debugged from inside VS Code. Running the identical code via mvn spring-boot:run on the command line always works, since that always compiles with javac.

To Reproduce

  1. Project with a lombok.config containing lombok.copyableAnnotations += org.springframework.context.annotation.Lazy (or any non-default copyable annotation).
  2. A class with @RequiredArgsConstructor and a @Lazy-annotated final field.
  3. Open/run the project in VS Code with redhat.java v1.55.0.
  4. Inspect the compiled class's constructor parameter annotations, or observe the Spring circular-dependency startup failure.

Expected behavior

The generated constructor parameter should carry the @Lazy annotation, matching javac/Maven output and the extension's own bundled Lombok agent when run standalone.

Versions

  • VS Code: 1.129.1 (macOS, auto-updated ~2026-07-10)
  • redhat.java (Language Support for Java): regression present in 1.55.0; confirmed absent in 1.54.0
  • Bundled Lombok agent in extension: lombok-1.18.39-4050.jar
  • Project's own Lombok version: 1.18.46 (ruled out as the cause, see above)
  • OS: macOS, darwin arm64
  • JDK: Temurin 21

Workaround

Pin the extension to v1.54.0 and set "extensions.autoUpdate": false to avoid silently regressing again.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions