Extension makes a '~' folder on Windows.

[kennethjohnsen]

When opening a folder containing a Gradle project, the extension makes a '~' folder inside the project folder.

Environment

• Operating System: Windows 11
• JDK version: 21
• Visual Studio Code version: 1.88
• Java extension version: 1.29.0

Steps To Reproduce

1. gradle init in empty folder.
2. vscode .
3. After extension has started, there is now a '~' folder inside the project folder.

Current Result

Expected Result

'~' folder should not be inside the project folder.

Additional Informations

[rgrunber]

Does the generated ~ folder contain any other folders/files ? It might help narrow down what is actually creating it. Do your VS Code user settings contain ~ anywhere ?

I just tried this out on Linux but didn't see the ~ folder. With that said, ~ is a shorthand for the home folder on Linux-based distros so I suspect the issue isn't happening there.

[kennethjohnsen]

Yes, there are some files in the folder. See screenshot.

[kennethjohnsen]

It looks like maybe it's trying to store something in .gradle in the users home folder, but for some reason, it creates the ~ folder here instead.
I have just tried the same thing on Linux, and it also makes the ~ folder.

However, I have found out that it also happens if I install the extension "Gradle for Java" by Microsoft.
This also happens on both Windows and Linux.
So maybe it's more related to Gradle than the extension itself?

[kennethjohnsen]

There is one line in my VSCode settings that has ~.
It says "java.import.gradle.user.home": "~/.gradle",

[kennethjohnsen]

Deleting the line with "java.import.gradle.user.home": "~/.gradle", seems to fix it.
The folder no longer appears.
The funny thing is, when I only have the "Gradle for Java" extension enabled, it also works now!
But the line with "java.import.gradle.user.home": "~/.gradle", is greyed out when I only have the Microsoft extension enabled, so it shouldn't be using that setting, but I guess it does.
Anyway, problem is fixed for me now, but the extension should probably handle the case where there is ~ in the setting.

[kennethjohnsen]

Ps. The linux I have tested with is my WSL Ubuntu, so code . starts the same (Windows) instance of VSCode.

[rgrunber]

The extension does mention it respects certain settings set by vscode-java : https://github.com/microsoft/vscode-gradle?tab=readme-ov-file#compatibility-with-the-java-language-support-extension . The fact that the settings are greyed out is just because they are contributed by vscode-java, so if it isn't installed, it detects that. However if extensions are querying the settings directly (even if greyed out), they will be discovered.

Did you every define "java.import.gradle.user.home": "~/.gradle" ? I can't find any code that would write the value out.

Another thing I noticed is that the setting isn't machine-overridable like other similar settings that might exist on a specific machine.

vscode-java/package.json

Lines 713 to 733 in 3ada59c

	"java.import.gradle.home": {
	"type": "string",
	"default": null,
	"description": "Use Gradle from the specified local installation directory or GRADLE_HOME if the Gradle wrapper is missing or disabled and no 'java.import.gradle.version' is specified.",
	"scope": "machine-overridable",
	"order": 40
	},
	"java.import.gradle.java.home": {
	"type": "string",
	"default": null,
	"description": "The location to the JVM used to run the Gradle daemon.",
	"scope": "machine-overridable",
	"order": 50
	},
	"java.import.gradle.user.home": {
	"type": "string",
	"default": null,
	"description": "Setting for GRADLE_USER_HOME.",
	"scope": "window",
	"order": 55
	},

. We could probably fix that which might prevent VS Code from re-using that setting back on the windows side.

[kennethjohnsen]

The extension does mention it respects certain settings set by vscode-java : https://github.com/microsoft/vscode-gradle?tab=readme-ov-file#compatibility-with-the-java-language-support-extension . The fact that the settings are greyed out is just because they are contributed by vscode-java, so if it isn't installed, it detects that. However if extensions are querying the settings directly (even if greyed out), they will be discovered.

Did you every define "java.import.gradle.user.home": "~/.gradle" ? I can't find any code that would write the value out.

Another thing I noticed is that the setting isn't machine-overridable like other similar settings that might exist on a specific machine.

vscode-java/package.json

Lines 713 to 733 in 3ada59c

	"java.import.gradle.home": {
	"type": "string",
	"default": null,
	"description": "Use Gradle from the specified local installation directory or GRADLE_HOME if the Gradle wrapper is missing or disabled and no 'java.import.gradle.version' is specified.",
	"scope": "machine-overridable",
	"order": 40
	},
	"java.import.gradle.java.home": {
	"type": "string",
	"default": null,
	"description": "The location to the JVM used to run the Gradle daemon.",
	"scope": "machine-overridable",
	"order": 50
	},
	"java.import.gradle.user.home": {
	"type": "string",
	"default": null,
	"description": "Setting for GRADLE_USER_HOME.",
	"scope": "window",
	"order": 55
	},

. We could probably fix that which might prevent VS Code from re-using that setting back on the windows side.

I don't remember ever setting "java.import.gradle.user.home": "~/.gradle" myself. I have had a lot of other extensions installed, though, so maybe one of them has set it at some point.
The setting does not reappear, though, so it doesn't seem to be set by any of the ones I have currently installed, which is good.

[rgrunber]

I guess we can close this for now. Going forward, I think machine-overridable should prevent these kinds of settings from applying to environments "outside" the host.