lsp4j
lsp4j copied to clipboard
eclipse-lsp4j
Migrate to Java 11
is the current release 3.16 complete or is there still something missing? i am not sure if we at Xtext already want to ditch Java 8 too. maybe source 11 target 8 could be an option?
JDT-LS made Java 11 a requirement a while ago (I believe due to Platform switching), and you can see much of the reaction to that at https://marketplace.visualstudio.com/items?itemName=redhat.java&ssr=false#review-details .
Not saying you should continue to support it despite difficulties, but if the work required to continue supporting is minimal it would reduce such complaints.
if the work required to continue supporting is minimal it would reduce such complaints.
I don't imagine end-users would typically complain about LSP4J version, it's an internal detail for them. So it's more about whether some LSP4J-based clients or server do care enough about Java 8 to make it still worth being supported. I don't think any form of complaints is worth keeping support for Java 8; unless those complaints are backed by contributions to match them. Java 8 support already did cost me about 20minutes + some CI cycles + probably 15 to 20 minutes to Jonah to figure out my mistake, and maybe more unnoticed more. I am personally not caring about Java 8 so this was pure loss to me, so if people care about Java 8 for LSP4J enough, I'd like their address to send them the bill of extra time Java 8 has cost today ;)
is the current release 3.16 complete or is there still something missing?
If I am reading between the lines correctly - do you recommend calling 3.16 done done before moving to Java 11. That is fine to me.
i am not sure if we at Xtext already want to ditch Java 8 too.
If Xtext moved that would signal 100% that LSP4J should move. Xtext has much wider user base AFAICT, many of them using it for years before LSP4J's existence.
maybe source 11 target 8 could be an option?
I don't think so - what spurred this today was using new library methods (specifically List.of today).
JDT-LS made Java 11 a requirement a while ago (I believe due to Platform switching), and you can see much of the reaction to that at https://marketplace.visualstudio.com/items?itemName=redhat.java&ssr=false#review-details .
That was a depressing read. Although it looked a lot like the hate when changing from Java 7 to 8. Nice to see some positive comments in there too.
Not saying you should continue to support it despite difficulties, but if the work required to continue supporting is minimal it would reduce such complaints.
I am 100% behind dropping Java 8 support. However I don't know how to reach the community of adopters before release. LSP4J doesn't have "users" in the sense of the extension point, yet I don't know how to reach those folks (as recently seen with https://github.com/eclipse/lsp4j/issues/536#issuecomment-812248984)
Thanks for the feedback.
I think it is fine to move to Java 11. A lot of other projects are already requiring it. Java 17 has been released, so we already have 2 other Java LTS interesting to support.
On personal side, the next release of Camel Language Server which is based on LSP4J will require Java 11.
So that's a +1 from me.
Thanks everyone for the feedback. I guess when we do the next release it will be Java 11 then.
I wish this to happen! Just FYI, IntelliJ IDEA started using Java 11 source language level a long time ago.
I really wish lsp4j to support JPMS (the module system) so we can use jlink on lsp4j!!
Thanks @ice1000. We are happy to receive PRs that include increase source level to Java 11.
Thanks @ice1000. We are happy to receive PRs that include increase source level to Java 11.
Oh really!! What about JPMS support? Are you okay with adding module-info.java?
Thanks @ice1000. We are happy to receive PRs that include increase source level to Java 11.
Oh really!! What about JPMS support? Are you okay with adding
module-info.java?
Sounds good to me. I have lived in OSGi / Eclipse land for a long time so not used JPMS, so as long as it doesn't interfere (which I don't expect it would) that would be very welcome.
@ice1000 if you want java11 and jlink to create executables, you should know that jpackage may be used with any source version. My LS is packaged with jpackage to produce executables for win/linux/macos and it uses pure lsp4j version without modifications
@ice1000 if you want java11 and jlink to create executables, you should know that jpackage may be used with any source version. My ls is packaged with jpackage to produce executables for win/linux/macos and it uses pure lsp4j version without modifications
I see. I was wrong about jlink -- I was unable to build javadoc jar with projects depending on lsp4j due to an error relevant to module-info, but it turns out to be a problem of the gradle task itself. Lsp4j is working fine.
@ice1000 feel free to check build.gradle.kts and ga-workflows here https://github.com/1c-syntax/bsl-language-server
I think it's better to migrate to Java 17 instead. For older java version support, you can use multi-release jar. The jar should also include module-info so users of lsp4j has the option to use jlink (it will complain if the jar is uses auto module).
i dont think it is a good idea to directly jump to java 17 only.
Any reason why besides issues with Gradle build?
it would forces all clients to use java 17 only and drop all support for older versions. we at Xtext are not ready yet. so we would have to stop supporting lsp4j newer versions alltogether with no reason beyond "they can" so i also would stop testing and contributing here until we are ready at xtext to support java 17 only.
as Xtext does not support java 17 source and target (it can run with java 17 against java 11 source and target) lsp4j would also need a replacement for Xtend
it would forces all clients to use java 17 only and drop all support for older versions. we at Xtext are not ready yet. so we would have to stop supporting lsp4j newer versions alltogether with no reason beyond "they can"
Hence I suggested to use multi release jars. So clients can use at Java 8 at minimum.
Hence I suggested to use multi release jars.
i dont know how that will work in osgi environments (e.g. lsp4e) also: what would be the benefit (for java 17 consumers) of that?
Hence I suggested to use multi release jars.
i dont know how that will work in osgi environments (e.g. lsp4e) also: what would be the benefit of that?
I don't know anything about osgi, so fair enough.
As for benefit - putting new cool syntaxes aside - you safe yourself from headaches when you try to upgrade for future LTS Java. They're a lot of deprecation happened to to Java 17. If you mean what's the benefit of multi release jar, you can include module-info into the jar while the jar still support Java 8 (Java 7 actually, but it's going to be deprecated).
I think it makes sense to jump to Java 11 for now. Java 11 adds JPMS which is very important (more important than the cool stuffs in Java 17)