Version 1.2.0 doesn't detect JDK installed via Homebrew well

[brunovieira97]

I've been using the extension for some time now. A couple of days ago, I've updated it to 1.2.0 and since then, when opening a study project it would report errors for everything.

Some of the errors include not finding Object's default no args constructor, failing to import basic core classes from Java (i.e. java.util, java.date), and so on.

I've already removed my JDK 17 installation, replacing it with JDK 11, and that had no effect. Only fix I've found is to rollback the extension to the previous version (1.1.0, from 3w ago).

Some screenshots are attached to show the errors I'm facing.

Environment

• Operating System: macOS 12.1 Monterey arm64 (Apple Silicon)
• JDK version: openjdk version "17.0.1" 2021-10-19, installed via Homebrew
• Visual Studio Code version: 1.63.2 (Universal)
• Java extension version: 1.2.0

Steps To Reproduce

1. Clone example project
2. Open project folder in VS Code
3. Open any .java file

Example project: https://github.com/brunovieira97/alura-novidades-java

Logs: Logs.zip

Current Result

Expected Result (v1.1.0)

Additional Informations

• Reinstalling the extension had no effect
• Tried removing VS Code completely and reinstalling as well
• As previously stated, I removed openjdk via brew and installed openjdk@11, properly linking it. No effect at all
• Log for "Language Support for Java (Syntax Server) shows this message, both with 1.1.0 and 1.2.0:

[Error - 13:29:00] Connection to server got closed. Server will not be restarted.

[snjeza]

@brunovieira97 could you try Clean the workspace directory

[brunovieira97]

Tried that before submitting the issue. Did not help. Even uninstalling the extension, or VS Code entirely had no effect at all.

[snjeza]

@brunovieira97 could you run

$ /opt/homebrew/opt/openjdk/bin/java -version
$ java -version
$ echo $JAVA_HOME
$ ls $JAVA_HOME/bin/javac

[brunovieira97]

Here it goes.

➜  ~ /opt/homebrew/opt/openjdk/bin/java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment Homebrew (build 17.0.1+1)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.1+1, mixed mode, sharing)

➜  ~ java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment Homebrew (build 17.0.1+1)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.1+1, mixed mode, sharing)

➜  ~ echo $JAVA_HOME


➜  ~ ls $JAVA_HOME/bin/javac
ls: /bin/javac: No such file or directory

$JAVA_HOME is not set as brew installation doesn't require that or sets such variable.
Instead, I've put java directly on my path via .zshrc like this:

export PATH="/opt/homebrew/opt/openjdk/bin:$PATH"

[snjeza]

Could you try the following:

$ export JAVA_HOME=/opt/homebrew/opt/openjdk
$ export PATH="/opt/homebrew/opt/openjdk/bin:$PATH"
$ ls $JAVA_HOME/bin/javac
$ javac -version
$ cd <your alura-novidades-java>
$ code .

[brunovieira97]

Still the same behavior. As I detailed previously, I have even uninstalled and installed other versions of the JDK and it had no impact.

The problem is clearly related to v1.2.0 of the extension. If I rollback to 1.1.0, as I said, no problems are reported for the source files.

Anyway, here's the output for the commands you recommended, after I exported $JAVA_HOME on my .zshrc file:

➜  ~ ls $JAVA_HOME/bin/javac
/opt/homebrew/opt/openjdk/bin/javac

➜  ~ javac -version
javac 17.0.1

[snjeza]

The problem is clearly related to v1.2.0 of the extension. If I rollback to 1.1.0, as I said, no problems are reported for the source files.

I can't reproduce it. Could you try the latest build - https://download.jboss.org/jbosstools/jdt.ls/staging/java-1.3.0-490/java-1.3.0-490.vsix

[brunovieira97]

Still facing the same problem with the 1.3.0 .vsix.

Did you try reproducing it with the same JDK, extension version and project?
I didn't test on my Windows machine, only on the Mac. Will try there as well and report if it happens.

Perhaps there are other specific logs or some way for me to demonstrate this issue on a Zoom call for any contributor? Let me know, I'm happy to help in any way I can.

[brunovieira97]

Could not reproduce the issue on my Windows laptop.

I'm using Settings Sync, and installed the same JDK distribution and version, as well as same version of all VS Code extensions and the editor itself.

Could it be related to the platform then?

[snjeza]

Could it be related to the platform then?

Yes, it could. I have tested on Linux and Windows.
cc @fbricon @rgrunber @testforstephen @jdneo

[mattwelke]

Can't reproduce on Linux. I was able to use Java 17 and Java 18 today using v1.2.0 of the extension.

However, I've had the issue you're describing here before. It was something to do with misconfigured JDKs. If I were you, I'd read over https://code.visualstudio.com/docs/java/java-project#_configure-runtime-for-projects and make sure the JDK you intend to use is included in that array of objects in the settings. Then, ensure that VS Code chooses the right JDK for your project by setting your toolchain version in your pom.xml or build.gradle file (depending on which you use). For example, I can get VS Code to choose the JDK I label as "JavaSE-17" in the settings by setting the following in my pom.xml file:

<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>

[testforstephen]

The default JDK path via brew install java is NOT a complete JDK home directory. It only has symbolic links to the bin folder, and other folders such as lib are not included.

The actual JDK home is placed at the subfolder libexec.

@brunovieira97 Regarding your machine, the correct JAVA_HOME should be /opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home, not /opt/homebrew/opt/openjdk.

Could you export $JAVA_HOME on your .zshrc file?

export JAVA_HOME="/opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home"

[testforstephen]

@Eskibear This is a new corner case that the new findJavaHome lib jdk-utils needs to cover better. Eskibear/node-jdk-utils#2

[Eskibear]

Homebrew creates a lot of symbolic links, I find we can only rely on <some-path>/bin/java, which is finally linked to the real installation location.

I've covered this case in latest jdk-utils. If you have a NodeJS runtime, you can run below command to test if your installed JDK is detected.

npx jdk-utils@0.4.1

Below is my smoke test.

$> ls -l /usr/local/opt/ | grep jdk
lrwxr-xr-x  1 sechs  admin  24 Dec 10  2020 java -> ../Cellar/openjdk/15.0.1
lrwxr-xr-x  1 sechs  admin  28 Dec 20 21:31 java11 -> ../Cellar/openjdk@11/11.0.12
lrwxr-xr-x  1 sechs  admin  24 Dec 10  2020 openjdk -> ../Cellar/openjdk/15.0.1
lrwxr-xr-x  1 sechs  admin  28 Dec 20 21:31 openjdk@11 -> ../Cellar/openjdk@11/11.0.12
lrwxr-xr-x  1 sechs  admin  24 Dec 10  2020 openjdk@15 -> ../Cellar/openjdk/15.0.1

$> cd /usr/local/opt/openjdk
$> ls -l bin/java
lrwxr-xr-x  1 sechs  staff  45 Sep 12  2020 bin/java -> ../libexec/openjdk.jdk/Contents/Home/bin/java

$> export PATH=/usr/local/opt/openjdk/bin:$PATH

$> npx jdk-utils@0.4.1
...
  {
    homedir: '/usr/local/Cellar/openjdk/15.0.1/libexec/openjdk.jdk/Contents/Home',
    isInPathEnv: true,
    hasJavac: true,
    version: { java_version: '15.0.1', major: 15 }
  },
  {
    homedir: '/usr/local/Cellar/openjdk@11/11.0.12/libexec/openjdk.jdk/Contents/Home',
    hasJavac: true,
    version: { java_version: '11.0.12', major: 11 }
  }
...

UPDATE

I just find on https://docs.brew.sh/Installation, location of homebrew is different per platform.

• /usr/local for macOS Intel, covered in jdk-utils@0.4.1.
• /opt/homebrew for Apple Silicon, which is @brunovieira97 's case.
• /home/linuxbrew/.linuxbrew for Linux.
  Later I'll cover all above cases in jdk-utils, and create a PR then.

[Eskibear]

Homebrew covered on both Apple Silicon and Linux in jdk-utils@0.4.2, see Eskibear/node-jdk-utils#5 (comment)

[testforstephen]

@brunovieira97
https://download.jboss.org/jbosstools/jdt.ls/staging/java-1.3.0-491/ has fixed this issue, pls try to download the new extension version java-darwin-arm64-1.3.0-491.vsix for Apple M1, and manually install the vsix to VS Code.

[brunovieira97]

@testforstephen was able to test today and it's working as expected now. Thank you for fixing this so fast, everyone!