VSCode extension JDK version

Installed version

• Spring Boot Extension Pack v0.0.8
• Spring Boot Dashboard v0.2.0
• Spring Boot Tools v1.25.0
• Spring Initializr Java Support v0.7.0

Looks like some code in the latest version is compiled against Java 11 (but prerequisites is JDK 8)

Activating 'vscode-spring-boot' extension
Found java exe: /opt/sdkman/candidates/java/8.0.282.hs-adpt/bin/java
isJavaEightOrHigher => true
Redirecting server logs to /dev/null
ERR: Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/springframework/ide/vscode/boot/app/BootLanguagServerBootApp has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)

Also reported here: https://github.com/microsoft/vscode-spring-boot-dashboard/issues/125

[martinlippert]

So to quickly fix this, change the settings via "spring-boot.ls.java.home" to point to a JDK >= 11.

[martinlippert]

@rubensa I very much agree that a “wider approach” makes sense here and that it would be good to unify the way the different extensions select and use the JDKs on the system. It would be good to find a common ground here to make this easier for the user.

When looking at this at the broader scope, I think we have two fundamentally different use cases here:

• (1) the extension itself requires a JDK to run on. The extension usually requires a specific minimum JDK level to run on, due to the extension itself being written in Java and compiled based on a specific minimum Java version.
• (2) user projects are configured for a specific Java version to compile against and probably can use the same but also a different JDK to run/debug the project.

Both cases are completely separate from each other and should not be mixed up, I think. Different projects might require different JDKs to compile/run against (even in the same workspace different projects might use different JDKs at the same time). Different extensions might need different JDKs as well to work with (e.g. the RedHat Java extension might use JDK14 in the future, whereas the Spring Boot extension still uses JDK11). So it is hard to come up with some unique setting the user defines (like java.home points to a JDK and we use that for everything). But it is also cumbersome for the user to define the individual JDKs all across the place using different settings and options. That is crazy.

One approach could be: We could come up with a unified way to let users define all the JDKs that are installed on their system (or whatever subset they would like to use). Maybe in some way like the RedHat Java extension defines the project JDKs: https://github.com/redhat-developer/vscode-java#project-jdks - but not specifically for projects, but as a general setting of configured JDKs to use.

Then, extensions could ask this unified list for a specific JDK (or a compatible one). So instead of searching for a JDK11 on its own, the Spring Boot language server could ask this unified component for a JDK >= 11 and that unified component would whatever Is configured in that list. In case extensions need to compile/run projects from the user, the extension could also lookup the available JDKs from that list and use them to compile/run against (or let the user even select which JDK to use then running an app).

@Eskibear What do you think?