Language Server fails to start with multiple --add-exports in java.jdt.ls.vmargs

[paulmedynski-microsoft]

The Language Server fails to start when multiple ---add-exports are specified in the java.jdt.ls.vmargs setting.

For example these VSCode settings (in .vscode/settings.json) start the Language Server correctly:

{
  "java.jdt.ls.vmargs": "--add-exports java.xml/com.sun.org.apache.xerces.internal.impl.dtd=ALL-UNNAMED",
  "java.trace.server": "verbose"
}

These settings do not:

{
  "java.jdt.ls.vmargs": "--add-exports java.xml/com.sun.org.apache.xerces.internal.impl.dtd=ALL-UNNAMED --add-exports java.xml/com.sun.org.apache.xerces.internal.xni.parser=ALL-UNNAMED --add-exports java.xml/com.sun.org.apache.xerces.internal.xni.grammars=ALL-UNNAMED --add-exports java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED --add-exports java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED"
  "java.trace.server": "verbose"
}

I see this error in the Language Support for Java output pane:

Error: Could not find or load main class java.xml.com.sun.org.apache.xerces.internal.xni.parser=ALL-UNNAMED
Caused by: java.lang.ClassNotFoundException: java.xml.com.sun.org.apache.xerces.internal.xni.parser=ALL-UNNAMED

I don't see any errors reported in the Chrome dev tools console, or in the Language Server workspace logs.

Environment

• Operating System: Windows 11 and WSL2 Debian 12
• JDK version: 21.0.1
• Visual Studio Code version: 1.88.1
• Java extension version: v1.30.2024041608 (pre-release)

Steps To Reproduce

1. Add multiple --add-exports arguments to the java.jdt.ls.vmargs value in VSCode settings.json.
2. Open a Java project workspace.

Current Result

The Language Server fails to start, and reports the above error to the Output pane.

Expected Result

The Language Server starts with all --add-exports supplied to the JVM.

[rgrunber]

I'm able to reproduce this as well. It's due to :

vscode-java/src/javaServerStarter.ts

Lines 310 to 318 in 34f54ac

	vmargs.forEach(arg => {
	// remove all standalone double quotes
	arg = arg.replace(/(\\)?"/g, ($0, $1) => { return ($1 ? $0 : ''); });
	// unescape all escaped double quotes
	arg = arg.replace(/(\\)"/g, '"');
	if (params.indexOf(arg) < 0) {
	params.push(arg);
	}
	});

. After the first --add-exports is pushed, the subsequent ones are skipped causing it to appear as if one of the arguments is being run as the main class.

@snjeza can you think of any JVM arguments that when duplicated would produce an issue starting up ? The code dates back to 2016 so maybe we should relax the restriction.

[snjeza]

can you think of any JVM arguments that when duplicated would produce an issue starting up ? #50 so maybe we should relax the restriction.

I agree, we should relax the restriction.

[paulmedynski-microsoft]

Thanks for the quick turnaround! Is there anything I can do with my local extension installation to make a similar change while I wait for the next release?

[rgrunber]

Once the change is merged, the pre-release stream should contain the fix the next day so you could definitely try that. I checked if there was some workaround to bypass the incorrect behaviour in a current released version, but there doesn't seem to be any.