Bundled Lombok crashes JDT indexing in 1.57.2026090508: ConstructorDeclaration.constructorCall NoSuchFieldError

[chagong]

Problem

redhat.java@1.57.2026090508 crashes the JDT background indexer through its bundled Lombok integration, even for a project that does not use Lombok. Java test/subject navigation then returns no matches. The previous prerelease, 1.57.2026090408, works on the same macOS runner.

Environment

• macOS 26.6.2, ARM64; GitHub runner image 20260831.0337.3
• VS Code 1.136.2
• Language Support for Java 1.57.2026090508 (darwin-arm64)
• JDT Core 3.48.0.v20260904-0811; compiler batch 3.46.200.v20260904-0811
• JDT LS 1.62.0.202609050810
• Bundled lombok-1.18.39-4050.jar
• Language-server JVM reports Java 21.0.12.1
• Debugger for Java 0.59.2026072407; Test Runner for Java built from 5a4ee47

Reproduction

The affected project is the Test Runner's JUnit fixture, whose POM has no Lombok dependency.

1. With Java prerelease 1.57.2026090508 and the default Lombok support setting, run the existing navigation tests.
2. Navigating from junit.App to its test should return junit5.AppTest; navigating back should return junit.App.
3. Both commands instead return items: [], and both assertions fail with 0 !== 1.
4. Set "java.jdt.ls.lombokSupport.enabled": false only in this fixture and start a fresh language-server session. Both navigation directions work again.

A complete macOS A/B workflow pins the failing Java extension and VS Code, builds the plugin, restores the original navigation implementation/assertions, and varies only the fixture's Lombok setting:

Control	Result
Lombok enabled	148 passing / 2 failing; indexer exception below
Lombok disabled	150 main + 1 unmanaged test passing; both navigation directions restored

The negative control intentionally fails. An additional original-source reproduction has the same 148/2 result without navigation instrumentation.

Exception and cause

The language-server log contains:

Background Indexer Crash Recovery
java.lang.NoSuchFieldError: Class org.eclipse.jdt.internal.compiler.ast.ConstructorDeclaration does not have member field 'org.eclipse.jdt.internal.compiler.ast.ExplicitConstructorCall constructorCall'
    at lombok.eclipse.EclipseAST.buildMethod(EclipseAST.java:467)
    at lombok.eclipse.EclipseAST.buildMethods(EclipseAST.java:457)
    ...
    at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.resolveDocument(SourceIndexer.java:197)
    at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexResolvedDocument(IndexManager.java:684)
    at org.eclipse.jdt.internal.core.search.processing.JobManager.indexerLoop(JobManager.java:541)

JDT commit 0928a958, "Unify the bifurcated constructor body", removes ConstructorDeclaration.constructorCall. Inspection of the actual old/new compiler JARs confirms the field was removed, while the bundled Lombok still accesses it.

Passive diagnostics show correct source URIs, primary types, and source/test search scopes, but zero TypeNameRequestor.acceptType callbacks from searchAllTypeNames, despite WAIT_UNTIL_READY_TO_SEARCH. Results are not being discarded by the navigation adapter. The inherited-method navigation case still passes through its different type/hierarchy lookup.

Why this appeared macOS-only

The original Windows and Linux jobs installed 1.57.2026090408; macOS installed 1.57.2026090508. The Marketplace currently lists the newer version only for darwin-arm64 and darwin-x64. This is a package-version difference, not evidence that the incompatible binaries are safe on other operating systems.

Pinning the previous prerelease or stable 1.56.0 also passes on macOS. Both original attempts of microsoft/vscode-java-test#1927 selected the bad package; the failure also predates that dependency-only PR.

Expected behavior / mitigation

Indexing should not crash in a non-Lombok project. Please ship a compatible JDT/Lombok combination, or retain a compatible JDT version until the Lombok integration supports the new constructor representation.

Disabling the unused Lombok integration is a demonstrated workaround for this test fixture, not a general recommendation for projects that require Lombok. I have not tested an alternative newer Lombok build or the failing package on Windows/Linux.

The original CI log collector looked in the normal Code profile and missed the exception. The reproducer collects the actual isolated test profile under .vscode-test/user-data/User/workspaceStorage/.../redhat.java/jdt_ws/.metadata/.log.

[datho7561]

I've noticed that a bunch of lombok-related tests started failing on jdtls. I guess that lombok hasn't adapted to internal changes made in jdt core?

[chagong]

Yep, that’s the mismatch here. This JDT change removed ConstructorDeclaration.constructorCall, but the bundled Lombok still accesses it in EclipseAST.buildMethod. That crashes indexing even in our non-Lombok fixture; disabling the Lombok integration restores navigation with the same JDT version.

[datho7561]

Filed upstream in lombok: projectlombok/lombok#4080 ; until it's fixed there, the lombok-related tests in jdtls will be failing.