FileSytemNotFound for src.zip when debugging on windows

[tgodzik]

Describe the bug

I added a workaround on Windows for this in https://github.com/scalameta/metals/pull/3265 However I wasn't able why it was the case and it only happens for src.zip.

To Reproduce

Steps to reproduce the behavior:

1. Start debugging session with a breakpoint in something that runs within a Thread (I reproduced it with FoldingRangeSuite in metals)
2. Exception will be thrown when translating the stack trace paths.
3. It's not possible to navigate to JDK sources in the thread stack.

Expected behavior

It's possible to navigate the whole thread stack.

Installation:

• Operating system: Windows
• Editor: Visual Studio Code/Atom/Vim/Sublime/Emacs
• Metals version: 0.10.8+36-cfa30f3f-SNAPSHOT

Additional context

Found it while preparing the latest release. I don't have time to delve deeper so a temporary wokraround should do.

Search terms

windows debugging stack

[melekhove]

I discovered that tests.debug.StepDapSuite.step-into-java-lib throws an exception while trying to create filesystem for the C:/Program%20Files/Java/jdk-18.0.1.1/lib/src.zip. In my case it happens when Bloop uses jdk1.8.0_181 (it was specified in ~.bloop\bloop.json ). With jdk-18.0.1.1 test fails because of other reason (line numbers don't match) but it is ok. After some investigation I discovered that under jdk1.8 StackFrame returned by scala-debug-adapter (which is used by bloop) returns jar:file:///C:/Program%2520Files/Java/jdk-18.0.1.1/lib/src.zip!/java.base/java/io/PrintStream.java As you can see there is extra %25 (which stands for % actually :-) ) and as result metal's attempts to get absolute path for the PrintStream.java fail. When started with jdk-18 StackFrame contains only %20 (space) and the rest is working fine.

So, if someone still uses old JDK he can expect similar issues.

[tgodzik]

@adpi2 any idea if this is something we can fix on the scala-debug adapter side?