Java tooling misresolves Gradle multi-module project refs (extra errored root + Go To Definition opens jar)

[Anand_Narasimhan1 (Anand Narasimhan)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Describe the Bug

In a plain, idiomatic Gradle multi-module project, Cursor’s Java tooling treats
an internal project-to-project dependency as if it were an external binary
(Maven-style) dependency. This produces two distinct, reproducible symptoms that
do not occur in VS Code running the same Red Hat Java extension versions
against the same project.

The repro is a minimal 3-module Gradle build with the dependency chain
app → service → common:

• service/build.gradle: api project(':common')
• app/build.gradle: implementation project(':service')

Both are standard Gradle project dependencies, and the build imports, compiles,
and runs cleanly (./gradlew clean run --args="world").

Bug 1 — Java Projects view shows an extra, errored root project.
The Java Projects explorer (vscjava.vscode-java-dependency) lists the three
real modules (app, common, service) plus an extra entry for the root
project, rendered in red with an error badge (1), even though the build
imports and compiles without errors.

Bug 2 — “Go To Definition” opens a built jar instead of project source.
Go To Definition on GreetingService (a type owned by the sibling :service
module) opens the decompiled class from service/build/libs/service-1.0.0.jar
instead of the real source at
service/src/main/java/com/example/service/GreetingService.java. The hover shows:

com.example.service.GreetingService
Source: service-1.0.0.jar = / version = / unknown / ... GreetingService.class

version = unknown is the tell — an internal project reference is being treated
as an external Maven-style binary dependency.

This is a tooling/consumption bug, not a build problem: every layer the language
server consumes expresses the dependency as project-to-source:

• ./gradlew :app:dependencies --configuration runtimeClasspath shows
  \--- project :service \--- project :common (project-based, no jar).
• The generated Eclipse/Buildship app/.classpath contains
  <classpathentry kind="src" path="/service"> and .../common (source
  references, no lib entry for service-1.0.0.jar).
• The project builds and runs cleanly via the Gradle wrapper.

Correct model in, jar-based resolution out.

Steps to Reproduce

1. Open the repro folder in Cursor with the Java extension pack installed
   (versions below).
2. Let the Java language server finish importing the Gradle project.
3. Open app/src/main/java/com/example/app/Main.java.
4. Bug 1: open the Java Projects view → observe an extra root entry (red,
   with a 1 error badge) alongside app, common, service.
5. Bug 2: Go To Definition (F12) on GreetingService → it opens the
   decompiled class inside service-1.0.0.jar instead of the .java source in
   service/.
6. For contrast, open the same folder in VS Code with the same extension
   versions: the extra root entry is absent and Go To Definition lands in the
   .java source.

Expected Behavior

• The Java Projects view lists only the real modules (app, common,
  service), with no extra/errored root entry — matching VS Code.
• Go To Definition on GreetingService opens
  service/src/main/java/com/example/service/GreetingService.java, not a
  decompiled class inside service-1.0.0.jar — matching VS Code.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Component	Version
Cursor	3.6.31
JDK	Amazon Corretto 25.0.3 (LTS)
Gradle (wrapper)	9.1.0
redhat.java	1.54.0
vscjava.vscode-gradle	3.17.3
vscjava.vscode-java-dependency	0.27.4
vscjava.vscode-java-pack	0.31.0

Does this stop you from using Cursor

Yes - Cursor is unusable

[mohitjain (Mohit)]

Both symptoms - the extra errored root entry and Go To Definition opening the jar instead of source - are caused by a known regression in the Red Hat Java extension (redhat.java) version 1.54.0.

To fix this, add the following to your Cursor settings (JSON):

"java.jdt.ls.scalaSupport.enabled": false

Then do a Java: Clean Language Server Workspace from the Command Palette and let the project re-import.

This is an upstream issue being tracked at vscode-java#4399, with a fix PR in progress. Once the fix ships in a future extension update, you’ll be able to re-enable Scala support if needed.

Regarding the VS Code comparison: this regression was also reported and confirmed against VS Code with the same extension version (1.54.0). If your VS Code install uses a slightly older version (1.53.x) or has a cached workspace from before the regression, that would explain the difference.

Let me know if the setting resolves both issues for you!