When viewing hover Javadoc, {@link ... that points to a binary class doesn't display as a link

[datho7561]

If you hover over a Java element that has Javadoc (eg. class, method, static/non-static member) that has a {@link org.example.ClassName} in it, the {@link is rendered as a link and is clickable if the class is a source file, but not if it is a binary file. For example, if you put {@link java.lang.String} in a Javadoc, then the hover documentation doesn't display a clickable link.

Environment

• Operating System: RHEL 8.6
• JDK version: The bundled Linux JustJ
• Visual Studio Code version: 1.73.1
• Java extension version: v1.13.2022111903 (prerelease)

Steps To Reproduce

1. Make a class file:

public class MyClass {

  /**
   * {@link java.lang.String}
   */
  public void myMethod() {
    myMethod();
  }
}

2. Hover over myMethod() to see the Javadoc

Current Result

The reference to java.lang.String is not clickable.

Expected Result

The reference to java.lang.String is a clickable link that opens java.lang.String in read-only mode.

Additional Informations

You can see in the extension output under the hover response that it tries to link to java.lang.String like this:

[java.lang.String](jdt://contents/java.base/java.lang/String.class?=quarkius/%5C/home%5C/davthomp%5C/.sdkman%5C/candidates%5C/java%5C/17.0.3-tem%5C/lib%5C/jrt-fs.jar%60java.base=/javadoc_location=/https:%5C/%5C/docs.oracle.com%5C/en%5C/java%5C/javase%5C/17%5C/docs%5C/api%5C/=/=/maven.pomderived=/true=/%3Cjava.lang%28String.class#140)

[rgrunber]

The jdt:// scheme is meant to be resolved by JDT-LS. We register a client-side provider at

vscode-java/src/providerDispatcher.ts

Lines 29 to 30 in ccb75b1

	const jdtProvider = createJDTContentProvider(options);
	context.subscriptions.push(workspace.registerTextDocumentContentProvider('jdt', jdtProvider));

, which ends up calling java/classFileContents on the server side to resolve the content.

Was this not working even when lsp4mp was using JavaContentAccess (before switching to 2) ?

Update : I would first confirm whether we have any other issues filed for this (in vscode-java, or JDT-LS), and if not maybe look at whether registerDocumentLinkProvider or some client-side API is needed to get the link working. We already have what's needed on the server-side to resolve the scheme.

Update 2 : If on the server-side the type is just a fully qualified String name, maybe something like :

JDTUtils.toUri(project.findType("some.qualified.Type").getTypeRoot()) can help ? it should get you jdt:// when the type root is from a classfile..

[datho7561]

We might not be able to fix this. It looks like VS Code used to be support opening URIs with any scheme at one point, and a few extensions relied on this, but it was patched out:
microsoft/vscode#151720

Then a feature request was opened to provide the old functionality as a feature, but it didn't receive enough votes and was auto closed:
microsoft/vscode#152716

edit: misread the code, looks like the command:// scheme might be supported