Navigation to *.class file (jdt:// scheme) is missing

[fbricon]

jdt.ls sends jdt:// uris for navigating to source code of classes in jar files. In vscode-java a provider is registered for the jdt scheme:

https://github.com/redhat-developer/vscode-java/blob/977973499608ccd5e64115876b250c5dae062023/src/extension.ts#L213-L221

https://github.com/redhat-developer/vscode-java/blob/56c5256f04b2d64208ff5346399cf2e1f94405aa/src/protocol.ts#L69-L71

[fbricon]

why isn't the code embedded in this issue?

[damieng]

Implementation notes:

• We'll need to add the JDT protocol via atom.workspace.addOpener
• When we see a request for that we obtain the contents via java/classFileContents
• Create a TextEditor and inject the contents in so we get syntax highlighting
• I wish we had a read-only text editor ...

[damieng]

@fbricon looks like we might just be able to wire the protocol handler up to the language server itself for obtaining the file contents?

Not sure what "code embedded in this issue" refers to.

[fbricon]

Yes calling java/classFileContents with that jdt uri will return the source, you don't need to worry about opening/traversing the jar.

For the embedded code, I'm talking about https://github.com/blog/2415-introducing-embedded-code-snippets. It seems to only work for code from the same repo.

[damieng]

Read only text editor coming in atom/atom#16294 which will unblock this

[fbricon]

FYI, I plan on disabling sending those jdt:// uris unless clients advertise they support it (see eclipse-jdtls/eclipse.jdt.ls#649). @damieng you might want to keep an eye on that one.

[fbricon]

With jdt.ls 0.19.0 (or more recent), clients need to declare their support for jdt:// urls by sending extendedClientCapabilities.classFileContentsSupport=true in initializationOptions. See eclipse-jdtls/eclipse.jdt.ls#649 (comment)