-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to Java 11 #547
Comments
is the current release 3.16 complete or is there still something missing? |
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. |
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. |
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.
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.
I don't think so - what spurred this today was using new library methods (specifically List.of today). |
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.
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 #536 (comment)) Thanks for the feedback. |
Seems good to me to make Java 11 a requirement. |
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. |
Oh really!! What about JPMS support? Are you okay with adding |
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. |
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 |
Awesome - thanks @nixel2007 for the guidance here. Much appreciated! |
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. as Xtext does not support java 17 source and target (it can run with java 17 against java 11 source and target) |
Hence I suggested to use multi release jars. So clients can use at Java 8 at minimum. |
i dont know how that will work in osgi environments (e.g. lsp4e) |
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) |
we are now on gradle 6. |
Lets migrate to Java 11.
Any objections?
The text was updated successfully, but these errors were encountered: