Latest Gradle Language Support extension cause hot code replace to fail.

[Mike-the-one]

Everything worked fine but until recently the hot code replace stopped working. I always keep my vscode up to date.

Last time I had this issue was caused by a bug in Debugger for Java extension. #850

So I suspected it again, downgraded it, also downgraded java language server, and vscode, cleared cache, workspace data etc, nothing helped... until I removed Gradle Language support extension.

Environment

• Operating System: Ubuntu
• JDK version: zulu openjdk 17
• Visual Studio Code version: 1.83.1
• Java extension version: latest
• Java Debugger extension version: latest

Steps To Reproduce

1. [step 1]
2. [step 2]

[attach a sample project reproducing the error]
attach logs

Current Result

Expected Result

Additional Informations

[DashieDev]

As i had a pretty similar issue which is resolved by the team, here is the quote from them:

We are exploring a new way of Gradle project support which may cause this issue (HCR not working).

In short, the new approach will directly leverage gradle itself to generate compiled class files. Before, it's the java extension itself to compile the project and generate the output into bin.

As a temporary workaround, you can set the setting java.gradle.buildServer.enabled to off and click the Reload button when the bottom-right notification pops up.

[douira]

I appear to be having the same issue. I've noticed that I can fix the issue temporarily by deleting all of VSCode's data in the Application Support (or the equivalent folder on other OSes). The issue soon came back though and once it appears HCR remains broken. I'm not sure what exactly the reproduction steps are, but when I build https://github.com/CaffeineMC/sodium-fabric then at some point hot reload says something to the effect of "there is no file to replace" even if there clearly was a change to a file (and I can confirm the file was saved and the build server did build it).

[douira]

I've tested the workaround and so far it appears to allow HCR to work again. Has the gradle extension's team been informed that there's issues with the interaction between this extension and the other one?

[Mike-the-one]

I wonder why this piece of experimental code is introduced into production code?

[scenariotrader]

Having same issues. Is this being addressed?

[testforstephen]

The root cause of the issue is that the new Gradle build server from vscode-gradle extension does not support auto build. As a result, it does not inform the Java debugger about the class files that have been modified, which in turn prevents the debugger from identifying the files that need to be hot replaced.

I created a dependent issue on the upstream vscode-gradle microsoft/vscode-gradle#1449.

[Mike-the-one]

Understood. then why cannot you wait for gradle extension to fix the problem before you prevent java extension to do the work? I assume lots of users are affected by this. Wasted me 5+ hours to figure this out.

This is the second time I found HCR bug.

The root cause of the issue is that the new Gradle build server from vscode-gradle extension does not support auto build. As a result, it does not inform the Java debugger about the class files that have been modified, which in turn prevents the debugger from identifying the files that need to be hot replaced.

I created a dependent issue on the upstream vscode-gradle microsoft/vscode-gradle#1449.

[mozhuanzuojing]

Even if the BSP is turned off("java.gradle.buildServer.enabled": "off"), the HCR does not take effect.

[huai-jie]

is there any update or temp solution on this? i facing this issue as well

[ImNoOSRS]

Same issue here i tried literally everything, DCEVM, diffrent arguments, hotswap agent jar, JDK11, 17, 20, 8
Gradle wrapper with java.gradle.buildServer.enabled off.....