Java 17 is mis-identified as Java 8

[dsyer]

Error message in VS Code (Source: Spring Boot Tools (Extension)):

Spring Tools Language Server requires Java 11 or higher to be launched. Current Java /opt/java/17.0.1/bin/java. (Note Java 8 can still be used in your own projects. Java 11 is only required to launch the Spring Tools Language Server process)

[BoykoAlex]

Tried Oracle Java 17 - it worked fine.
Which Java 17 did you install?

[dsyer]

I just opened a random project in codespaces, so whatever that gives you, I guess. I might have asked for Java 17 explicitly but I don’t recall.

[martinlippert]

I have tried this one here (https://github.com/martinlippert/codespaces-spring-test2) with a JDK17, that seems to work when I open that in Codespaces in a browser window. Can you share the random project where you observe this issue? And did you open Codespaces in a browser or via your local VSCode?

The version check that causes the above error message uses the output of java -XshowSettings:properties to identify the Java version (java.version property), so it might be interesting to see the output of this for the JDK mentioned in the above error message (from within a terminal in the Codespaces workspace).

[dsyer]

I'm in the browser (local VSCode with Codespaces never seems to work for me). Here's the output from that command. It's weird because it doesn't use /opt/java/17.0.1/jdk at all. So that setting is coming from somewhere?

$ java -XshowSettings:properties
Property settings:
    awt.toolkit = sun.awt.X11.XToolkit
    file.encoding = UTF-8
    file.separator = /
    java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
    java.awt.printerjob = sun.print.PSPrinterJob
    java.class.path = 
    java.class.version = 55.0
    java.home = /opt/java/11.0.8
    java.io.tmpdir = /tmp
    java.library.path = /usr/java/packages/lib
        /usr/lib64
        /lib64
        /lib
        /usr/lib
    java.runtime.name = OpenJDK Runtime Environment
    java.runtime.version = 11.0.8+10
    java.specification.name = Java Platform API Specification
    java.specification.vendor = Oracle Corporation
    java.specification.version = 11
    java.vendor = AdoptOpenJDK
    java.vendor.url = https://adoptopenjdk.net/
    java.vendor.url.bug = https://github.com/AdoptOpenJDK/openjdk-support/issues
    java.vendor.version = AdoptOpenJDK
    java.version = 11.0.8
    java.version.date = 2020-07-14
    java.vm.compressedOopsMode = 32-bit
    java.vm.info = mixed mode
    java.vm.name = OpenJDK 64-Bit Server VM
    java.vm.specification.name = Java Virtual Machine Specification
    java.vm.specification.vendor = Oracle Corporation
    java.vm.specification.version = 11
    java.vm.vendor = AdoptOpenJDK
    java.vm.version = 11.0.8+10
    jdk.debug = release
    line.separator = \n 
    os.arch = amd64
    os.name = Linux
    os.version = 5.4.0-1064-azure
    path.separator = :
    sun.arch.data.model = 64
    sun.boot.library.path = /opt/java/11.0.8/lib
    sun.cpu.endian = little
    sun.cpu.isalist = 
    sun.io.unicode.encoding = UnicodeLittle
    sun.java.launcher = SUN_STANDARD
    sun.jnu.encoding = UTF-8
    sun.management.compiler = HotSpot 64-Bit Tiered Compilers
    sun.os.patch.level = unknown
    user.country = US
    user.dir = /workspaces/jmolecules-integrations
    user.home = /home/codespace
    user.language = en
    user.name = codespace
    user.timezone = 

The output from the vscode-spring-boot-debug-log is here:

Activating 'vscode-spring-boot' extension
"spring-boot.ls.java.home" setting not specified or empty value
"java.home" setting not specified or empty value
No user specified java-home setting. Looking for JAVA_HOME env variable...
found JVM at location "/opt/java/17.0.1/jre" is not a JDK
Trying to find JDK corresping to currently found JRE. Checking for JDK at /opt/java/17.0.1/jdk
Found java executable: /opt/java/17.0.1/bin/java

and in a terminal:

$ env | grep JAVA
JAVA_ROOT=/home/codespace/.java
JAVA_HOME=/opt/java/lts
$ ls -l /opt/java/lts
lrwxrwxrwx 1 codespace codespace 6 Dec 10 19:56 /opt/java/lts -> 17.0.1

and

$ /opt/java/17.0.1/bin/java -version
openjdk version "1.8.0_265"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.265-b01, mixed mode)

So that's where it comes from, but AFAIK it's nothing to do with me. I just open the project in the browser.

The project I opened was this one: https://github.com/xmolecules/jmolecules-integrations (but the problem is not unique to that repository).

[martinlippert]

This one is really strange:

$ /opt/java/17.0.1/bin/java -version
openjdk version "1.8.0_265"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.265-b01, mixed mode)

Why is there a JDK 1.8.0 under the 17.0.1 path? Really strange setup from Codespaces, but it at least explains why the Spring Boot extension complains about the JDK it tries to use is not a JDK >= 11... ;-)

Maybe this is related to the project being defined for a compilation level of Java 1.8 and the Java tooling tries to be smart about this, but this is just guessing...

So that's where it comes from, but AFAIK it's nothing to do with me. I just open the project in the browser.

Yeah, understand, I can reproduce this in a browser using Codespaces as well. I guess you just opened the Codespaces workspace for the project and then installed the Java Extension Pack as well as the Spring Boot Extension Pack into this Codespaces workspace, right?

You could fix this problem by specifying the JDK location for the Spring Boot extension in the preferences via: spring-boot.ls.java.home and then set this to the JDK that Codespaces uses a current: /home/codespace/.java/current/bin/java (which would be the JDK11 in your case).

[dsyer]

It's completely baffling. I opened a support ticket with Github but I'm not sure that can be public. I opened a public issue here: microsoft/vscode-dev-containers#1245 as well.

[martinlippert]

I tend to close this issue as a duplicate of the one you mentioned above. We could theoretically change the logic of how the extension tries to find the right JDK to somehow deal with this situation, but since there is a JAVA_HOME specified that the extension tries to use (as a last resort before checking specific preferences), I think we should leave it the way it is. Okay?

[dsyer]

I guess. It seems like JAVA_HOME could easily point to the wrong version anyway, even without this stupid codespaces issue. It might be good to be able to look in other well known locations as well, before failing.

[martinlippert]

This is the strategy that the extension uses:

• look for the Spring Boot extension specific preference (spring-boot.ls.java.home)
• look for the Java Language Extension preference for the JDK (java.home)
• look for the JAVA_HOME env variable
• look for the PATH env variable

The problem might be that the check for the JDK >= 11 happens after this strategy found a JDK (from top to bottom), it does not continue the search if one of the found JDKs is < 11. In your case it looks like the first two options are not set, then JAVA_HOME is found pointing to a JDK and is used, but then recognized as JDK < 11.

So we could improve the strategy to continue the search if the found JDK is not >= 11 as well as add additional locations to the list of searched locations. WDYT?

[BoykoAlex]

Think it might be fixed indirectly while fixing #715