The debug protocol has support for this: https://github.com/Microsoft/vscode-debugadapter-node/blob/master/protocol/src/debugProtocol.ts#L244
But VS Code uses native paths when communicating with the DA.
Flipping this switch in VS Code would probably break many debug extensions that are not prepared for passing URIs instead of native paths.
So we have to find a way around this...

Currently language server protocol textDocument/definition supports uri in its response Location, and supports user customized TextDocumentContentProvider to parse the special uri scheme (e.g. jdt://contents/rt.jar/java.io/PrintStream.class).

But vscode debugger doesn't support setBreakpoints in the user customized editor. See the code debugConfigurationManager.ts#canSetBreakpointsIn. It's a problem that the user is able to view the third party source via go to definition feature, but cannot set breakpoints there.

If the debug protocol has some configuration items to allow the specific uri schemes to be set breakpoints in, it would be better.
@weinand @isidorn

@weinand What about adding a new field 'uri' to DebugProtocol.Source and deprecated 'path'.
When 'uri' is set, it will be used instead of the path. In messages to the debug adapter, both should be set for backward compatibility.

@aeschli before we discussing solutions to the problem, let's try to understand the problem first.

@testforstephen's comment from above says:

vscode debugger doesn't support setBreakpoints in the user customized editor.

VS Code supports setting breakpoints for "languages" that are registered for breakpoints (this is the "breakpoints" contributions point).

Has this been done for the "class" files?

If not, you can easily enable setting breakpoints everywhere via the "debug.allowBreakpointsEverywhere" setting.

If breakpoints have been registered for "class" and you still cannot set breakpoints, then this is a bug.

The gif shows the problem.

• when going to a declaration that is inside a JAR or has a source attachment, the Java language server returns a custom URI for a virtual resource: jdt://contents/rt.jar/java.io/PrintStream.class.
• the Java extension registers a resource provider for these URIs. The content is provided on demand by the language server
• .class files are registered to the java language mode. The debug adapter enables breakpoint for java, but setting breakpoint doesn't seem to work
• when debugging and stepping inside a class file, the debug adapter would like to return the same URI: jdt://contents/rt.jar/java.io/PrintStream.class so that the debug UI can open that resource. But source.path is limited to file paths, so that doesn't work.
• Currently, the debug adapter returns class file contents through the inMemory mechanism, which leads to two different editors for the same content. Also, setting breakpoints isn't possible ahead of debugging.

@aeschli if setting breakpoints still doesn't work, then this is a bug. @isidorn could you please investigate.

The other issue is already being solved as we speak. The DA will be able to pass jdt://contents/rt.jar/java.io/PrintStream.class as a Source.path and VS Code will not assume that it is an native path but treat it as a uri.

Thanks for pointing this out.
There was an issue in the debug code that it allowed breakpoints only for certain schemas which was bogus. This was orignally introduced to prevetn setting breakpoints in settings files, but now I simple disable setting brekapoints in .json always. Or at least until a json debugger comes along hehe.
With the vscode insiders from monday you shuold be able to nicely set breakpoints in all your .class files

This is now nicely supported also via 22d7830

Anyways you should be able to send a string uri in Source.path. And it will get properly handled here https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/common/debugSource.ts#L33

@testforstephen let us know if it nicely works for you