Initialize Java runtimes config based on "Installed JREs" pref page

[akurtakov]

I see "Unbound classpath container: 'JRE System Library [JavaSE-11]' in project 'org.eclipse.jdt.compiler.tool.tests'" from jdt.ls.client while testing it. Using the preferences of the IDE to fill the RuntimeOption[] as described in https://github.com/eclipse/eclipse.jdt.ls/wiki/Running-the-JAVA-LS-server-from-the-command-line#initialize-request should hopefully silence these.

[akurtakov]

The full details error is:

Description	Resource	Path	Location	Type
Unbound classpath container: 'JRE System Library [JavaSE-19]' in project 'test'	test		Unknown	Language Servers

[akurtakov]

There is one more which I guess is caused by this one:

Description	Resource	Path	Location	Type
The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files	module-info.java	/test/src	line 1	Language Servers

[akurtakov]

To reproduce in empty workspace just create test project with module-info.java

[rgrunber]

Have a look at https://github.com/eclipse/eclipse.jdt.ls/blob/5bdac979161b34cae73b9ed66733b5d867cce9d8/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/JVMConfigurator.java#L202 . This gets called during initialization. So I think if you set "java" : { "home" : { "/path/to/some/default/jvm/17/" } within the initializationOptions of initialize, it should work.

Anything more advanced, and you'd probably want to use java.configuration.runtimes. Maybe since you're already in Eclipse, you can take advantage of the Execution Environment settings and populate this with those values.

[mickaelistria]

This is one of the issues that would automatically be fixed without effort or tweak if we can have JDT-LS running in a thread.

[akurtakov]

So should we not look into this one but concentrate on the in-process or it's worth having it so we can actually start using jdt.ls.client now?

[mickaelistria]

The 3 currently knowb blockers for the in-process approach have fixes proposed as PRs and even if those fixes are not accepted as-it, the issue do seem relatively affordable to fix. So I've good hope that we can have in-process working in the IDE soon enough. I believe it's better to concentrate on it for a couple of weeks, and according to the outcome, either go full steam on it or revise the strategy to keep the LS external.

[akurtakov]

Can you refer to the jdt.ls prs here for completeness?

[mickaelistria]

Current blockers are

• Add support for skipping propagation of TextEdit eclipse-jdtls/eclipse.jdt.ls#2312
• JDTLanguageServer cannot run well without IApplication eclipse-jdtls/eclipse.jdt.ls#2311
• The filesystem hack should be in a dedicated bundle eclipse-jdtls/eclipse.jdt.ls#2309

I suspect there will be a few others in the future.
Another one that is not a technical blocker but an oragnizational one that makes work much harder and way less efficient is the fact that JDT-LS uses an old LSP4J. I'm going to try upgrading that.

[mickaelistria]

Another blocker is eclipse-jdtls/eclipse.jdt.ls#2351 ; andother annoyign one (not blocker but really really hard to live with as it makes Eclipse IDE confused and breaking and requiring tons of hacks) is eclipse-jdtls/eclipse.jdt.ls#2348