Java build mixes Redhat Extension and Gradle binaries

Support Bug Reports
, ,
1

Describe the Bug

I have a multi-project gradle build.
Project ‘webapp’ depends on project ‘common’.
If I do a ‘Java: Clean Java Language Workspace’ the operation fails unless I then run the gradle jar task on the common project.
If I change something in the common project I have to remember to re-run the gradle common jar task in order to make it available to the webapp project.

I shouldn’t have to micro-manage the build between the two projects in this way:
the ‘clean workspace’ command should automatically rebuild the two projects without me having to interleave gradle tasks.

It seems to me that the problem is down to mixing build products from the redhat Language Support for Java extension and the Gradle build, and the solution is for the classpath for webapp to refer directly to the redhat product of the common project rather than to the gradle product.
I note that the current classpath appears to refer to both the project and to the gradle generated jar file, which suggests some confusion as to how it is supposed to work. Indeed, if I manually remove the common jar from the classpath (but keeping the common project) the rebuild succeeds, but this is not a viable work-around as at some point the original classpath will be re-instated based on the gradle project definitions.

Steps to Reproduce

Configure a two-project build where B depends on A.
Clean all gradle projects (equivalent to deleting the build directories in each project).
Run the ‘Java: Clean Java Language Workspace’ command.
The automatic java build fails complaining that B can’t be built because A.jar doesn’t exist.
Edit the java classpath to remove the A.jar library.
The build will re-start and will be successful.
Touch one of the build.gradle files.
The build will re-start and will fail again, citing the missing A.jar library file.

Expected Behavior

The ‘Java: Clean Java Language Workspace’ command should rebuild multi-project gradle projects without manual intervention and without running any gradle tasks.

Operating System

Windows 10/11

Version Information

Version: 3.10.17 (user setup)
VS Code Extension API: 1.125.0
Commit: c89f45b831621cdc5e951694db44fecd8fab1150
Date: 2026-07-05T06:39:45.228Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Gary_Parden

This looks like this thread which was already raised back in the Spring. Have a look.

7

Hi @Colin yesterday’s release appears to have fixed this problem for me - the classpath no longer includes the gradle build product common.jar, and it does appear to have built successfully.

Unfortunately it has exposed or caused a different problem:

View → Testing

This command opens the testing activities view, but says ‘No tests have been found in this workspace yet’.

Java code is no longer painted with test runner icons.

I expected in both cases for the system to recognise multiple junit5 test cases/suites.

The RedHat extensions reports 2 uncaught errors (image below).

Junit5 tests were recognised and runnable as of Monday 6/Jul.

Gary.

image
image782×499 33.8 KB

8

Apparently, downgrading to v1.54 of the RedHat extension makes it work again! I’ve just tested it, and indeed, the tests show up when I browse View → Testing (and they didn’t when I had 1.55 installed).

You can do so from here:

image
image1734×890 144 KB

9

Yes, downgrading the redhat extension to 1.5.4 has fixed the problem.

I have also disabled all extension auto upgrades.

Thanks, Gary.