Special characters in a branch name causes the extension to fail

[Roemer]

In my setup, someone (accidently) created a branch with an umlaut (ö). Even without checking out this branch, the extension fails immediately with the following error:

[Error - 7:52:05 AM] Jun 7, 2023, 7:52:05 AM Initialization failed 
Malformed input or input contains unmappable characters: /workspaces/project/.git/refs/remotes/origin/feature/Sortierungsm��glichkeiten
java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /workspaces/project/.git/refs/remotes/origin/feature/Sortierungsm��glichkeiten
	at java.base/sun.nio.fs.UnixPath.encode(Unknown Source)

Environment

• Operating System: Windows 10 with WSL2 and a VSCode Remote-Container inside WSL2
• JDK version: openjdk 17.0.6 2023-01-17
• Visual Studio Code version: 1.78.2
• Java extension version: v1.19.0

Steps To Reproduce

1. Clone https://github.com/Roemer/java-umlaut-test.git
2. Switch to the branch with a special character: git checkout HelloWörld
3. Open the java file to start the java language server
4. Check the output of Language Support for Java

Current Result

The error occured:

[Error - 9:22:28 AM] Jun 7, 2023, 9:22:28 AM Initialization failed 
Malformed input or input contains unmappable characters: /workspaces/java-umlaut-test/.git/refs/heads/HelloW��rld
java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /workspaces/java-umlaut-test/.git/refs/heads/HelloW��rld
	at java.base/sun.nio.fs.UnixPath.encode(Unknown Source)
	at java.base/sun.nio.fs.UnixPath.<init>(Unknown Source)
	at java.base/sun.nio.fs.UnixFileSystem.getPath(Unknown Source)
	at java.base/java.nio.file.Path.of(Unknown Source)
	at java.base/java.nio.file.Paths.get(Unknown Source)
	at org.eclipse.core.internal.filesystem.local.nio.PosixHandler.fetchFileInfo(PosixHandler.java:41)
	at org.eclipse.core.internal.filesystem.local.LocalFileNativesManager.fetchFileInfo(LocalFileNativesManager.java:87)
	at org.eclipse.core.internal.filesystem.local.LocalFile.fetchInfo(LocalFile.java:161)
	at org.eclipse.core.filesystem.provider.FileStore.fetchInfo(FileStore.java:260)
	at org.eclipse.core.filesystem.provider.FileStore.childInfos(FileStore.java:99)
	at org.eclipse.core.internal.localstore.UnifiedTree.getLocalList(UnifiedTree.java:360)
	at org.eclipse.core.internal.localstore.UnifiedTree.addChildren(UnifiedTree.java:148)
	at org.eclipse.core.internal.localstore.UnifiedTree.addNodeChildrenToQueue(UnifiedTree.java:254)
	at org.eclipse.core.internal.localstore.UnifiedTree.accept(UnifiedTree.java:120)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.refreshResource(FileSystemResourceManager.java:978)
	at org.eclipse.core.internal.localstore.FileSystemResourceManager.refresh(FileSystemResourceManager.java:961)
	at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1573)
	at org.eclipse.core.internal.resources.Project.open(Project.java:1094)
	at org.eclipse.core.internal.resources.Project.open(Project.java:1150)
	at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.create(ProjectConfigurationManager.java:845)
	at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.lambda$1(ProjectConfigurationManager.java:153)
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
	at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
	at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.importProjects(ProjectConfigurationManager.java:139)
	at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.importProjects(ProjectConfigurationManager.java:130)
	at org.eclipse.jdt.ls.core.internal.managers.MavenProjectImporter.importToWorkspace(MavenProjectImporter.java:241)
	at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.importProjects(ProjectsManager.java:150)
	at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.initializeProjects(ProjectsManager.java:112)
	at org.eclipse.jdt.ls.core.internal.handlers.InitHandler$1.runInWorkspace(InitHandler.java:254)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:43)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Expected Result

No error occurs

Additional Informations

It seems that this does not happen on Windows, just when using Linux (or WSL2 in my case)

[daxia4444]

i have this issue, why not have anyone handler it ?

[sumpingc]

In my case this solved it (with DevContainer).

• Operating System: macOS 13.6.1 with DevContainer
• JDK version: openjdk 17.0.9 2023-10-17
• Visual Studio Code version: 1.84.2
• Java extension version: v1.24.0

{
  ...
  "remoteEnv": {
    "LC_ALL": "en_US.UTF-8"
  },
  ...
}

so, maybe in your WSL2

export LC_ALL="en_US.UTF-8"

I hope it helps you.

[Roemer]

It seems this is not only for branch names but also when any filenames with special characters are encountered (even non-java files).

[Roemer]

"remoteEnv": {
"LC_ALL": "en_US.UTF-8"
},

This workaround in dev containers does indeed work, thanks for that.