JDK 14/15 support

[Jonpez2]

Thing one: thank you for the excellent project. I've been using it without a hitch for several months now, and it has enabled me to set up a Bazel-based pure-web development environment for my team. Superb.

So: what is the process by which we can upgrade the javac used for parsing etc? Specifically I'd love to enable preview features in a jdk14 javac, or even better (though probably much harder) I'd love to make the javac and its argument dependent on the specific configuration from the appropriate BUILD.bazel.

I'm happy to PR if that's the way you would like me to go, but I definitely need some direction on how you would like it to work.

Thank you!

[georgewfraser]

It should just be a matter of bumping the version of Java used to build it, like so: https://github.com/georgewfraser/java-language-server/commit/6f0fe9f5b4441eec8f29565d704ce69dce47b62a

If you make a PR, please write a test that shows that it works with some JDK-14 feature.

[Jonpez2]

OK I have that working, with a test. Doing it the simple way means that we require the ambient jdk to be >=14, and means that I turn on preview features. Are you ok with that, or would you prefer more configurability?

If you want more configurability, do you want me to ask the compiler whether it's >=14, and then turn on enable preview if so; or do you want me to add something to the vscode config so people can control extra params? Or something else?

Thank you!

On Wed, Aug 26, 2020 at 8:12 PM George Fraser notifications@github.com wrote:

It should just be a matter of bumping the version of Java used to build it, like so: 6f0fe9f https://github.com/georgewfraser/java-language-server/commit/6f0fe9f5b4441eec8f29565d704ce69dce47b62a

If you make a PR, please write a test that shows that it works with some JDK-14 feature.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/georgewfraser/java-language-server/issues/165#issuecomment-681071011, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABN425MYSXMG73R7ZKTSLZDSCVNDNANCNFSM4QLVAYNA .

[georgewfraser]

we require the ambient jdk to be >=14

To build this project, yes. But users on older JDKs should still be able to run the language server, because it's built as a standalone distributable.

[Jonpez2]

Hmm, I think we might be talking at cross purposes. My end goal is to make it so that my project is parsed using jdk14 with --enable-preview, preferably as controlled by some bazel config. I don't think that actually requires the build version of java-language-server to tick up; we 'just' need to discover the right jdk and the right parameters. So I've done step one, which proves that we can make java-language-server run under jdk14 and parse with preview features; step two, of allowing control over the javac and its config, is where I'm looking now.

Am I missing the point?

Thanks!

On Fri, Sep 11, 2020 at 3:08 AM George Fraser notifications@github.com wrote:

we require the ambient jdk to be >=14

To build this project, yes. But users on older JDKs should still be able to run the language server, because it's built as a standalone distributable.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/georgewfraser/java-language-server/issues/165#issuecomment-690829992, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABN425LSD53KQVORREKAKJLSFGBCFANCNFSM4QLVAYNA .

[Jonpez2]

Hello again. Now that jdk15 is out, I'd really love to understand how I can run java-language-server under 15 with --enable-preview. I must be missing something obvious, so I apologize for asking the same question.

Thank you!

On Fri, Sep 11, 2020 at 10:12 AM Jonathan Perry jonpez63@gmail.com wrote:

Hmm, I think we might be talking at cross purposes. My end goal is to make it so that my project is parsed using jdk14 with --enable-preview, preferably as controlled by some bazel config. I don't think that actually requires the build version of java-language-server to tick up; we 'just' need to discover the right jdk and the right parameters. So I've done step one, which proves that we can make java-language-server run under jdk14 and parse with preview features; step two, of allowing control over the javac and its config, is where I'm looking now.

Am I missing the point?

Thanks!

On Fri, Sep 11, 2020 at 3:08 AM George Fraser notifications@github.com wrote:

we require the ambient jdk to be >=14

To build this project, yes. But users on older JDKs should still be able to run the language server, because it's built as a standalone distributable.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/georgewfraser/java-language-server/issues/165#issuecomment-690829992, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABN425LSD53KQVORREKAKJLSFGBCFANCNFSM4QLVAYNA .

[georgewfraser]

The way this extension works is it's packaged as a standalone executable. This is a little-used feature of Java but it's been around for a while. What this means is that a slimmed-down copy of java is packaged alongside the extension. So that's the version of Java you're using when you run this extension, even if you have a different version installed on your system.

The good news is that because Java is quite good about backwards-compatibility, the solution is to just bump to jdk15.

[Gilwe]

Hey @georgewfraser I can confirm that this standalone Jar can't run with Java 16.

SEVERE  Main main   superclass access check failed: class org.javacs.ReusableCompiler$ReusableContext (in unnamed module @0x40f9161a) cannot access class com.sun.tools.javac.util.Context (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.util to unnamed module @0x40f9161a
java.lang.IllegalAccessError: superclass access check failed: class org.javacs.ReusableCompiler$ReusableContext (in unnamed module @0x40f9161a) cannot access class com.sun.tools.javac.util.Context (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.util to unnamed module @0x40f9161a
    at java.base/java.lang.ClassLoader.defineClass1(Native Method)
    at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1010)
    at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
    at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:855)
    at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:753)
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:676)
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at org.javacs.JavaCompilerService.<init>(JavaCompilerService.java:15)
    at org.javacs.JavaLanguageServer.createCompiler(JavaLanguageServer.java:112)
    at org.javacs.JavaLanguageServer.compiler(JavaLanguageServer.java:39)
    at org.javacs.JavaLanguageServer.foldingRange(JavaLanguageServer.java:353)
    at org.javacs.lsp.LSP.connect(LSP.java:442)
    at org.javacs.Main.main(Main.java:30)

[delabassee]

It's simple to tweak this extension to make it work with the latest (local) JDK version, ex. it works with OpenJDK 19 initial Release Candidate. Enabling Preview Features and Incubator Modules is also easy. Now given the 6 months release cadence, does it still make sense to embeds jlink'ed JDKs?

[georgewfraser]

@delabassee CI works a lot better now, so it's easy to publish new versions. It would be nice if there were an option to specify a local JDK. PR welcome!