Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#4,467 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
java, vscode
Bereich
developer-experience, devtools

Rechercherichtung

Reproduziere die Regression in der redhat.java v1.55.0 jdt.ls-Integration unter Verwendung der gezeigten lombok.config und des @RequiredArgsConstructor-Beispiels. Vergleiche die Annotationen der generierten Konstruktorparameter mit javac, dem gebündelten ECJ/Lombok-Batch-Setup und der Extension v1.54.0; abgeschlossen ist die Aufgabe, wenn @Lazy beim Kompilieren über den laufenden Language Server vorhanden ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug

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 [email protected] --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.

Vorherrschende Sprache
TypeScript
Sterne
2.3k
Forks
548
Ø Merge
3 T. 8 Std.
Gemergte PRs (30 T.)
10

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus redhat-developer/vscode-java

Alle Issues in redhat-developer/vscode-java

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.