search

scalameta / metals-vscode

Visual Studio Code extension for Metals
https://marketplace.visualstudio.com/items?itemName=scalameta.metals#overview
Apache License 2.0
300 stars 76 forks source link

Add options for import java.compiler module #1395

Closed VankaTaganai closed 1 year ago

VankaTaganai commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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.