False positive "Flexible Constructor Bodies is only available with source level 25 and above" with Lombok @RequiredArgsConstructor on Java 21

Description

I am seeing a false-positive Java compiler diagnostic in VS Code when using Lombok @RequiredArgsConstructor in a Java 21 Maven project.

The project compiles and installs successfully with Maven, but VS Code reports:

The Java feature 'Flexible Constructor Bodies' is only available with source level 25 and above

The source code itself does not use Flexible Constructor Bodies or any Java 25 syntax.

Environment

VS Code Java extension: redhat.java@1.57.2026093008 (pre-release)
Project source level: Java 21
Build system: Maven
Lombok: used through Maven dependency / annotation processing
mvn install: SUCCESS

Minimal reproducer

import lombok.RequiredArgsConstructor;

@RequiredArgsConstructor
public class Test {

    private final String value;
}

Maven configuration:

<properties>
    <maven.compiler.release>21</maven.compiler.release>
</properties>

Steps to reproduce

Create a Maven project targeting Java 21.
Add Lombok.
Create a class containing a final field.
Add Lombok @RequiredArgsConstructor.
Open the project in VS Code with redhat.java@1.57.2026093008.
Let the Java Language Server finish importing and analysing the project.

Actual behavior

VS Code reports:

The Java feature 'Flexible Constructor Bodies' is only available with source level 25 and above

even though the source code does not contain a constructor using Flexible Constructor Bodies.

The error appears to be related to the constructor generated by Lombok.

Expected behavior

No Java 25 / Flexible Constructor Bodies diagnostic should be reported.

The generated constructor is equivalent to ordinary Java 21-compatible code:

public Test(String value) {
    this.value = value;
}

Maven result

The project builds successfully:

mvn install
BUILD SUCCESS

Therefore the issue appears to be limited to VS Code / JDT Language Server diagnostics rather than the Maven compiler configuration.

Additional information

The same issue occurs in a real Spring project using:

@RequiredArgsConstructor
public class ProdCatalog {

    private final DoubleThrower<RestFunctionsException, RuntimeException> thrower;

    private final NamedParameterJdbcTemplate jdbc;
}

There is no explicit constructor in the class.

The diagnostic is therefore likely triggered during Lombok/JDT AST processing of the generated required-arguments constructor.

I am using the 1.57 pre-release because of a separate issue present in 1.56.0, so reverting to 1.56.0 is not currently a practical workaround.

Please let me know if a Java Language Server log, Lombok version, complete pom.xml, or a minimal reproducer repository would be useful.

I managed to replicate this. It's also filed upstream in lombok: projectlombok/lombok#4084 . vscode-java reuses parts of Eclipse. Lombok support in Eclipse relies on a bunch of hacks to the internals of Eclipse's Java compiler (ECJ), so sometimes when there's new features, fixes or refactorings in that compiler, it breaks Lombok.

From my past experience, lombok is slow to address these things, but it seems like ~~one of the committers~~ someone who contributes to the project frequently has assigned themselves, so maybe it'll be addressed at some point.

I managed to replicate this. It's also filed upstream in lombok: projectlombok/lombok#4084 . vscode-java reuses parts of Eclipse. Lombok support in Eclipse relies on a bunch of hacks to the internals of Eclipse's Java compiler (ECJ), so sometimes when there's new features, fixes or refactorings in that compiler, it breaks Lombok.

From my past experience, lombok is slow to address these things, but it seems like ~~one of the committers~~ someone who contributes to the project frequently has assigned themselves, so maybe it'll be addressed at some point.

@datho7561

@datho7561 thanks, in the meantime we downgraded to 1.55 where no such problem appears.

Same issue on the stable release.

Environment

Operating System: Windows
JDK version: Oracle JDK 21.0.10 (build 21.0.10+8-LTS-217)
Visual Studio Code version: 1.96.4
Java extension version: 1.57.0 (1.56.0 works)
Lombok: 1.18.30; also reproduced with 1.18.42

Notes

Tried without success: restarting the language server, cleaning the Java workspace, reinstalling the Java Extension Pack, upgrading Lombok.
Disabling built-in Lombok support and pointing -javaagent at lombok-1.18.42.jar removed the Flexible Constructor Bodies error, but Lombok then didn't take effect ("The blank final field ... may not have been initialized").
Downgrading to 1.56.0 resolves it for me.

me too!

I had the same issue with Java 21 and Lombok 1.18.46. Gradle compiled fine, but VS Code kept showing this error. Downgrading the Java extension to 1.56.0 fixed it for me. Thanks for sharing the workaround!

Seeing the same thing, but on Java 17 and with other Lombok annotations, so it doesn't look specific to @RequiredArgsConstructor or Java 21.

Environment

vscode-java 1.57.0 (auto-updated today), macOS arm64
Bundled Lombok: lombok-1.18.39-4050.jar
Project: Gradle, toolchain JavaLanguageVersion.of(17), Lombok 1.18.30

Symptoms

~250 errors across 56 files: The Java feature 'Flexible Constructor Bodies' is only available with source level 25 and above

Every error is reported on a Lombok annotation (@Getter / @Builder / @Jacksonized). Example:

@Getter
@Builder
@Jacksonized
public final class AAAAAAAARule {
  private final String code;
  private final Integer durationSeconds;
  ...
}

'I've received your email and will will reply to you as soon as possible after the vacation.————————————This is an auto reply email from QQ Mail.'

similar issue, java 25 project with lombok
all lombok SuperBuilder don't compile

Cannot read field xxx in an early construction context

same question in java17 project

Welp, this bug forced me to downgrade back to 1.56.0

yes, back to 1.56.0

Yup, I downgraded the extension back to 1.56.0 too!

Same problem here, and downgrading solve the problem...

Apparently, 1.57 only supports java25 or above. Our project is java21, we had to downgrade to 1.56. NOTE, java21 is an LTS, it should be available for a few more years at least. Furthermore, it is a requirement imposed upon us by the (big-big corporate) client, we are unable to change it in any reasonably short time frame.

@installed

I’m using Java 21 and everything was good until I updated, and now I’m getting the same error as everyone here. Will have to downgrade to 1.56.0 for what i see.

It’s very likely that Cursor and VS Code have shipped or automatically updated to Red Hat Java 1.57.0. You might want to try rolling back to version 1.56.0.

How to roll back to version 1.56.0:
1-) Open Extensions: Click the Extensions icon (four squares).
2-) Find the Java extension: Type @installed redhat java or Language Support for Java(TM) by Red Hat in the search box. The publisher should be Red Hat.
3-) Open its detail page: Click the extension itself (not just the list row) to view its full description, version number, and other details.
4-) Install another version: Click the gear ⚙️ icon on the extension entry (sometimes located in the detail page header). Select Install Another Version… from the menu.
5-) Select version 1.56.0: Choose 1.56.0 and avoid 1.57.x. Confirm the installation and reload Cursor if prompted.

I encountered the same issue, and downgrading to version 1.56.0 fixed it for me.

Apparently, 1.57 only supports java25 or above. Our project is java21, we had to downgrade to 1.56. NOTE, java21 is an LTS, it should be available for a few more years at least. Furthermore, it is a requirement imposed upon us by the (big-big corporate) client, we are unable to change it in any reasonably short time frame.

I'm using Java 25 and I had to downgrade to 1.56 too :(

     I'm using Java 25 and I had to downgrade to 1.56 too :(

Well, the specific error seems to affect both java versions. The version limitation in 1.57 is then strange coincidence :) But still a problem for a lot of projects in itself.

Here is what worked for me:

code --install-extension redhat.java@1.56.0 --verbose

Well, the specific error seems to affect both java versions. The version limitation in 1.57 is then strange coincidence :) But still a problem for a lot of projects in itself.

jdtls, the language server that powers vscode-java's features, requires Java 25 to run as of the latest version. vscode-java bundles a copy of the JRE it needs to run jdtls (i.e. 1.57.0 bundles a copy of Java 25), so you shouldn't need to install it yourself for the extension to work. You should still be able to work on projects as old as Java 8 with vscode-java.

My understanding is that the problems being reported here are caused by lombok; lombok doesn't support the latest version of Eclipse's internal compiler, which this extension makes use of.

I think downgrading to 1.56.0 is the best path forward if you're working with lombok. There's not much we can do on our end to address this until this is fixed upstream lombok. Lombok has been fairly slow to adopt to the latest release of Eclipse's internal compiler, so this might take a while.

     ...
     You should still be able to work on projects as old as Java 8 with vscode-java.
     ...
     There's not much we can do on our end to address this until this is fixed upstream lombok. Lombok has been fairly slow to adopt to the latest release of Eclipse's internal compiler, so this might take a while.

Got it, thx.

23. > Well, the specific error seems to affect both java versions. The version limitation in 1.57 is then strange coincidence :) But still a problem for a lot of projects in itself.

 jdtls, the language server that powers vscode-java's features, requires Java 25 to run as of the latest version. vscode-java bundles a copy of the JRE it needs to run jdtls (i.e. 1.57.0 bundles a copy of Java 25), so you shouldn't need to install it yourself for the extension to work. You should still be able to work on projects as old as Java 8 with vscode-java.
 My understanding is that the problems being reported here are caused by lombok; lombok doesn't support the latest version of Eclipse's internal compiler, which this extension makes use of.
 I think downgrading to 1.56.0 is the best path forward if you're working with lombok. There's not much we can do on our end to address this until this is fixed upstream lombok. Lombok has been fairly slow to adopt to the latest release of Eclipse's internal compiler, so this might take a while.

There has been some progress upstream: eclipse-jdt/eclipse.jdt.core#5489 identified the underlying Lombok/ECJ compatibility issue, and a backward-compatibility fix has already been merged in PR #5490.
While Lombok is also working on adapting to the new ECJ AST structure, upgrading Lombok may not be feasible for projects with pinned dependencies. Currently, we having to downgrade vscode-java to 1.56.0 as a workaround.
Could the next vscode-java release include a JDT Core/ECJ build containing this compatibility fix? This would help restore compatibility with existing Lombok versions without requiring changes to project dependencies.

I can confirm this issue with redhat.java 1.57.0 on Java 17 and Lombok 1.18.36. In our case the problem is more severe than an incorrect diagnostic: the Eclipse/JDT compilation performed by VS Code actually produces an invalid .class file for a Lombok-generated builder.

We get:

java.lang.ClassFormatError: Invalid method Code length 0 in class file
nl/rivm/dvp/rvp/machine/model/ComponentPlanning$ComponentPlanningBuilder

Inspecting the generated class with javap -v shows that with redhat.java 1.57.0 the Lombok-generated constructor has an empty Code attribute:

ComponentPlanning$ComponentPlanningBuilder();
  descriptor: ()V
  flags: (0x0000)
  RuntimeInvisibleAnnotations:
    0: #8()
      lombok.Generated
  Code:
    stack=0, locals=1, args_size=1
    LocalVariableTable:
      Start  Length  Slot  Name   Signature
          0       0     0  this   Lnl/rivm/dvp/rvp/machine/model/ComponentPlanning$ComponentPlanningBuilder;

We isolated this from Maven compilation. After deleting the generated builder .class, merely touching ComponentPlanning.java while VS Code is running causes the Java language server to regenerate the invalid class.

Downgrading only redhat.java from 1.57.0 to 1.56.0 and repeating exactly the same test produces valid bytecode:

Code:
  stack=1, locals=1, args_size=1
     0: aload_0
     1: invokespecial #14  // Method java/lang/Object."<init>":()V
     4: return

After the downgrade, the ClassFormatError disappears and the affected Cucumber tests run normally from VS Code Testing.

Environment:

Java:        17
Lombok:      1.18.36
vscode-java: 1.57.0 (broken)
vscode-java: 1.56.0 (works)

So this issue can affect not only editor diagnostics, but also the bytecode emitted by the incremental Eclipse/JDT compilation.

Navigation Menu

Repository navigation

False positive "Flexible Constructor Bodies is only available with source level 25 and above" with Lombok @RequiredArgsConstructor on Java 21 #4521

Description

Environment

Minimal reproducer

Steps to reproduce

Actual behavior

Expected behavior

Maven result

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

False positive "Flexible Constructor Bodies is only available with source level 25 and above" with Lombok @RequiredArgsConstructor on Java 21 #4521

Description

Description

Environment

Minimal reproducer

Steps to reproduce

Actual behavior

Expected behavior

Maven result

Additional information

Activity

datho7561 commented on Oct 5, 2026

tomas-bucki-pds commented on Oct 5, 2026

acarcher commented on Oct 13, 2026

Kerbores commented on Oct 14, 2026

danrriv commented on Oct 14, 2026

chrispyleLAC commented on Oct 14, 2026

maomaoke commented on Oct 14, 2026

germandsantana commented on Oct 14, 2026

zhaiang commented on Oct 14, 2026

TotoShampoin commented on Oct 14, 2026

zhaiang commented on Oct 14, 2026

chrispyleLAC commented on Oct 14, 2026

JimmyRampage commented on Oct 14, 2026

javobalazs commented on Oct 14, 2026

MrItzreal commented on Oct 14, 2026

TIS-liuz commented on Oct 14, 2026

JimmyRampage commented on Oct 14, 2026

javobalazs commented on Oct 14, 2026

2buisson commented on Oct 14, 2026

datho7561 commented on Oct 14, 2026

javobalazs commented on Oct 14, 2026

Hou-Xiaoxuan commented on Oct 14, 2026

hanjoosten commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions