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

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions