Add options for import java.compiler module

[VankaTaganai]

This changes related to Java Hover for Metals. It's required to export java.compiler module manually for Java version greater than 17. I've handled version of Java like it's made in Metals.

[dos65]

Works well!

I just submitted a minor fix onto your branch - I realized that we actually have an actual javaHome and there is no need to extract it back from env.

[dos65]

@ckipp01 @ayoub-benali - Hey! Could you say if you will be able to port changeset from this PR for nvim and sublime?
They are needed for better java support in case if jvm is greater or eq of 17.

[ckipp01]

@ckipp01 @ayoub-benali - Hey! Could you say if you will be able to port changeset from this PR for nvim and sublime? They are needed for better java support in case if jvm is greater or eq of 17.

Thanks for the ping @dos65! I haven't been following the work on the Java hover pr, but how come this is actually necessary? I don't mean why are the extra flags necessary, but how come they need to be used to start Metals? I was under the assumption that when Metals started the java compiler or whatever was being used it could pass in those flags so the client doesn't need to worry about them. Is that at all possible, or is absolutely necessary that Metals is started with those flags?

To answer your original question, I think this should be portable, I just need to rewrite it in lua for nvim-metals.

[ayoub-benali]

Hey @dos65, from my understanding a set of flags are passed to the client if java_home is 17 or above. It shouldn't be a problem to do that for sublime

[dos65]

@ckipp01

Thanks for the ping @dos65! I haven't been following the work on the Java hover pr, but how come this is actually necessary? I don't mean why are the extra flags necessary, but how come they need to be used to start Metals? I was under the assumption that when Metals started the java compiler or whatever was being used it could pass in those flags so the client doesn't need to worry about them. Is that at all possible, or is absolutely necessary that Metals is started with those flags?

Yep, unfortunately it's necessary. It doesn't affect Metals startup but in runtime for jdk17 there will be errors in case of JavaPC execution. We can't pass there flags as JavaPC is not a separate process, Metals runs it in the same way as ScalaPC.
I was googling a bit but haven't found any reliable workaround.

I theory there is an option to make some kind metals-launcher that can detect jdk version and run actual process with or without flags and doing an proxy for stdin/stdout. However, this solution has more drawbacks rather than making such changes in clients.