JDK 13 support for Gradle

[manastalukdar]

Just updated to JDK13. None of the java imports and primitives are recognized. Any known issues with JKD13? Cleaned language server workspace with the same result.

Environment

• Operating System: Windows 10 x64
• JDK version: 13
• Visual Studio Code version: 1.39.0 (Insiders)
• Java extension version: 0.49.0

Steps To Reproduce

1. Create JDK13 project in VSCode
2. Open Java file

Entry in .classpath file (jdk 13):

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-13/"/>

Multiple exceptions in output from Extension:

Can't convert '13' to enum type 'JavaVersion'

Caused by: java.lang.IllegalArgumentException: Cannot convert string value 'VERSION_13' to an enum value of type 'org.gradle.api.JavaVersion' (valid case insensitive values: VERSION_1_1, VERSION_1_2, VERSION_1_3, VERSION_1_4, VERSION_1_5, VERSION_1_6, VERSION_1_7, VERSION_1_8, VERSION_1_9, VERSION_1_10, VERSION_11, VERSION_12, VERSION_HIGHER)

[fbricon]

JDK 13 support has not been released yet. You can start vscode-java with it but can't compile against it. You can use the latest CI build (0.50.0.*) available from https://download.jboss.org/jbosstools/jdt.ls/staging/?C=M;O=D
See https://twitter.com/VSCodeJava/status/1174738189304651776

[manastalukdar]

@fbricon Thanks for the latest CI link. It works, except with junit: (Repo here)

If and when there is a fix, I will be happy to test it out.

[fbricon]

Please provide a sample project reproducing this issue. It should just work if junit Jupiter is on the classpath.

[manastalukdar]

Here is a sample repro project: https://github.com/manastalukdar/dummy-java

[fbricon]

So the problem seems to be coming from the Gradle integration with Eclipse. Not sure this is Gradle itself or Buildship. In Eclipse, even with the latest Gradle 6.0 CI build, when the project is imported, the Java environment is set to JavaSE-11 instead of JavaSE-13. @donat whose fault is that?

[manastalukdar]

@fbricon Is there any workaround for the time being? Perhaps something I could manually edit in some metadata file...

[donat]

The Buildship-side seems fine to me. I've imported the sample project above (with Gradle 5.6.2, Buildship 3.1.2, Eclipse 2019-09 containing Java 13 support from the Marketplace). When I set the sourceCompatibility and the targetCompatibility to 13, then the Gradle synchronization set the expected JRE.

[fbricon]

@donat you mean you switched from 13 to 1.13? Your screenshot shows 13 in build.gradle

[donat]

I meant 13. I've edited my response above. Sorry about the confusion.

[fbricon]

Ok it works if I move the sourceCompatibility and targetCompatibility properties outside of the compileTestJava block. What I actually did before, which didn't work, was to set those properties in a compileJava block:

compileJava {
   sourceCompatibility = 13
   targetCompatibility = 13
   options.compilerArgs += ['-parameters', '-g']
}

@donat looks like this a bug (similar setup is referenced in https://stackoverflow.com/a/28513930), or is that behavior no longer supported by Gradle?

[manastalukdar]

@fbricon The issue still exists with both 0.50 stable and 0.51 CI builds of the language server extension.

Update: 0.50 has been explicitly marked as JDK 13 support for Eclipse, Maven only. I guess gradle support is WIP.

[donat]

@fbricon This is the expected behavior. Buildship loads the Java versions from the eclipse.jdt block, which is either explicitly set or defaults to project.sourceCompatibility and project.targetCompatibility. Consequently, the values in the compileJava {} block are ignored.

[astrelsky]

So I managed to resolve this locally from the advice here eclipse-jdtls/eclipse.jdt.ls#1196 (comment)

I launched eclipse and waited the usual 20 minutes for it to start. Waited another 20 minutes for it to transition to the welcome screen. Added the snapshot to grab that update and then exited eclipse. I then searched my user directory for 'buildship' and located the following two jar files:

C:\Users\{user}\.p2\pool\plugins\org.eclipse.buildship.core_3.1.3.v20191025-2152-s.jar
C:\Users\{user}\.p2\pool\plugins\org.gradle.toolingapi_6.0.0.v20191025-2152-s.jar

I then copied those two files into C:\Users\{user}\.vscode-insiders\extensions\redhat.java-0.53.0\server\plugins
I then opened C:\Users\astre\.vscode-insiders\extensions\redhat.java-0.53.0\server\config_win\config.ini and replaced@4,reference\:file\:org.eclipse.buildship.core_3.1.2.v20190903-1732.jar with @4,reference\:file\:org.eclipse.buildship.core_3.1.3.v20191025-2152-s.jar and @4,reference\:file\:org.gradle.toolingapi_5.6.1.v20190903-1732.jar with @4,reference\:file\:org.gradle.toolingapi_6.0.0.v20191025-2152-s.jar

After that I re-opened vscode, cleaned the language server workspace and after a couple seconds I was able to work again (debug, build, test, etc.). Is this method recommended? No. I just hope it pushes things in the right direction.

[fbricon]

I'm testing 3.1.3 in jdt.ls builds. Hopefully we should be able to provide a CI build tomorrow