Add optional support for class files with file scheme

Hello,

I use emacs with eglot. I noticed that sometimes, jdt.ls returns URIs on the form jdt:// when trying to find a definition. Eglot does not handle these URIs.

Is it possible to configure jdt.ls to use file:// protocol instead? I noticed that other packages parse jdt:// and convert them to something useful (I see that emacs’s lsp-java and nvim nvim-jdtls do that. I suspect vscode does as well).

Excuse my naivity as I don’t now the design and purpose of return jdt:// uris (not sure what that protocol is meant for).

[dannyfreeman]

Not really. Eglot and lsp-mode are different lsp clients with different design philosophies.

But that is beside the point. The code itself wouldn’t be that hard to write. Support for this bespoke URL format for this one specific server probably won’t make it into Eglot and Emacs core, it will end up in a separate package that someone has to write and maintain. So out of the box, this lsp server won’t play very nicely with Emacs and will require the user to install extra packages for it to work correctly. That’s not the end of the world. Maybe other lsp-clients require users to download extra packages to support servers like jdtls and users are fine with that. I don’t know though.

[rgrunber]

If we ended up creating a separate file for every .class that could get very complicated. It would have to be stored per-project and get re-generated every time we detect the underlying library changed. I agree we should try to make it easier for clients to implement such functionality, and having more things to implement client side does reduce the likelihood of clients taking full advantage of features. It might be possible to create an extended client capability that informs the server whether the client intends to support jdt:// . The server could then respond with either jdt or file, depending on the client’s setting. Still, having to write out each classfile to the filesystem on-demand would likely slow things down.

Is there some uri scheme, we could return from 'textDocument/definition` that most clients will support ? Doesn’t look like it.

We use the query string portion (the part of after the ?) in order for JDT to uniquely identify the classfile :

jdt://contents/java.base/java.lang/String.class?=json-example_96bcdf0c/\\/usr\\/lib\\/jvm\\/java-17-openjdk\\/lib\\/jrt-fs.jar`java.base=/javadoc_location=/https:\\/\\/docs.oracle.com\\/en\\/java\\/javase\\/17\\/docs\\/api\\/=/<java.lang(String.class

https://github.com/eclipse/eclipse.jdt.ls/blob/6c61f23f3b9818d6e54c993095a710ad51600cfc/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/JDTUtils.java#L390-L395

That’s definitely custom enough that nothing is going to support this, which is why the client is forced to query the server once again, in order to get the proper content to display to the user.

I’ve marked this as an enhancement since it could benefit other clients, but the work to support jdt:// is just a matter of extending the client’s existing “document type registry”, querying JDT-LS once more, and returning the resulting content in the “document type registry provider”.