Add Installed JREs view

[snjeza]

The view will show all installed JREs in Java LS and mark if any of java.configuration.runtimes aren't recognized.

The related issue - #3799 (comment)

[rgrunber]

See #1969 (comment) , #2115 (comment)

I think this is done by https://github.com/microsoft/vscode-java-pack/blob/main/src/java-runtime/index.ts from the Java extension pack. I know we've wanted to move it into vscode-java in the past.

[snjeza]

It would be good to have a separate view (similar to Eclipse's Window>Preferences>Installed JREs page) to show invalid java.configuration.runtimes and more info about installed JREs: name, path, environment...

[tsmaeder]

@rgrunber the trouble with that view is that it only works when the import of the workspace has resulted in any java projects. In general, the problem many user seem to have is that stuff fails in the setup phase and they are incapable of analyzing what the problem is. Looking at the Eclipse .log file is not a feasible debugging strategy for folks not intimately familiar with the Eclipse IDE (which is the majority, these days).

I think some kind of "Java Dashboard" might be a good idea that collects the configuration data that is effectively used, like "which JDK is used by Gradle to launch the daemon and where can I change it". For example, I was thinking vscode-java was not detecting my installed JRE's because they did not show up in the settings.json file. Turns out they are only detected once and passed to jdt.ls. The JRE's we see in the view are again something different: they include the JRE the language server runs on, which might not be in the detected JRE's that are passed as an initialization parameter to jdt.ls.

Once we can collect that info, we could offer a "collect troubleshooting data" action that puts the config into a zip file with the relevant logs for easy attachment to a bug report.

[rgrunber]

Wouldn't it be enough to just include more initialization data into the existing server logs ? No one has to know about the Eclipse logs as we've made it easier to get to them through the UI. For example, just clicking on the Java server status icon (or searching for a command from the palette that contains "logs") brings up :

The detected JDKs as well as the runtime used (whether for Gradle or to launch the language server itself) can all be collected and shown in the logs as part of the activation. I don't really have anything against some kind of UI that just displays all that information, that you can simply "Copy data" and paste it wherever. I think the main issue is how to make it very discoverable and then what value a UI adds over a simple text file if they're both brought up the same way.

[tsmaeder]

Wouldn't it be enough to just include more initialization data into the existing server logs

What do you mean by "server logs"? The output channel named (Language Support for Java)?

I'm not really married to any particular way to present this to the user (a "Java Dump debug info" that writes it to the output channel might be just fine) , but IMO an eclipse .log or the language server message log are not really actionable resources for an end user not familiar with vscode-java implementation. They are essential for vscode-java and jdt.ls developers, though.

From the little I've seen from actual customers, many problems seem to be: "it does not import my project" and "it does not detect my source folders correctly" and I think a lot of them could be prevented if we gave folks more insight into what's going on in a simple way.