Open LakshyAAAgrawal opened 12 months ago
@LakshyAAAgrawal Could you run
$ ls -l path/to/downloaded/binaries/jdks/openlogic-openjdk-8u392-b08-linux-x64/bin/java
$ path/to/downloaded/binaries/jdks/openlogic-openjdk-8u392-b08-linux-x64/bin/java -version
username@machinename:/path/to/dir$ ls -l path/to/downloaded/binaries/jdks/openlogic-openjdk-8u392-b08-linux-x64/bin/java
---x------ 1 USERNAME USERDOMAIN users 8776 Oct 18 15:23 path/to/downloaded/binaries/jdks/openlogic-openjdk-8u392-b08-linux-x64/bin/java
username@machinename:/path/to/dir$ path/to/downloaded/binaries/jdks/openlogic-openjdk-8u392-b08-linux-x64/bin/java -version
openjdk version "1.8.0_392-392"
OpenJDK Runtime Environment (build 1.8.0_392-392-b08)
OpenJDK 64-Bit Server VM (build 25.392-b08, mixed mode)
You can try
$ sudo setfacl -m <your_username>:rwx /path/to/dir
reinstall JDK
I tried the above command, and have also tried giving the jdk8 binaries all permissions (777) with chmod. It still gives the same error.
Regarding reinstalling JDK, I have already tried with 3 different packages of JDK-8 (linked above). I downloaded JDK-17 in exactly the same way, and the binaries from JDK-17 have exactly the same permissions as above, but it works fine, while JDK-8 is the only one causing the issue.
Can you try adding the following as a system property to the JDT-LS launch : -DDetectVMInstallationsJob.disabled=true
. I assume it would need to go at https://github.com/microsoft/monitors4codegen/blob/ae4499082c15fd46f54c539d28b3504feb4cd082/src/monitors4codegen/multilspy/language_servers/eclipse_jdtls/eclipse_jdtls.py#L109-L123 .
See https://github.com/redhat-developer/vscode-java/blob/b1d08312b3d986368afbbe56e9271b4f9d6758fc/src/javaServerStarter.ts#L136 as an example of a client that does this.
@mickaelistria , looks like DetectVMInstallationsJob
is one of the jobs failing. Do any of the above errors look familiar? @LakshyAAAgrawal is /usr/lib/jvm/java-8-openjdk-amd64
a symbolic link ? Most often an entry like that in the jvm/
folder would point to the fully qualified folder name. I still think launching java
that way should work but maybe there are issues with this.
Can you try adding the following as a system property to the JDT-LS launch :
-DDetectVMInstallationsJob.disabled=true
.
...and
"java.configuration.detectJdksAtStart": false,
to settings.json
Caused by: org.eclipse.core.runtime.AssertionFailedException: null argument:
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:88)
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:76)
at org.eclipse.jdt.internal.launching.CommandLineShortener.<init>(CommandLineShortener.java:78)
at org.eclipse.jdt.internal.launching.CommandLineShortener.<init>(CommandLineShortener.java:74)
at org.eclipse.jdt.internal.launching.StandardVMRunner.getCommandLine(StandardVMRunner.java:503)
at org.eclipse.jdt.internal.launching.StandardVMRunner.run(StandardVMRunner.java:531)
at org.eclipse.jdt.launching.AbstractVMInstall.evaluateSystemProperties(AbstractVMInstall.java:398)
is a recurrring issue with some VM installations. I've not been able to reproduce it myself to fix it, but there are issue such as https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1190 which show that under some circumstances, JDT fails. I don't know for sure what's wrong here: the detect VM job or even JDT entirely. I will try to try it (yes, "try to try") with the suggest links, hoping I can reproduce it and hopefully fix it in JDT.
Note that the DetectVM job has received improvements in the last months. So can you please first check the version of org.eclipse.jdt.launching that is being used when reproducing this issue?
LSP: window/logMessage: {'type': 3, 'message': 'Nov 19, 2023, 2:01:18 PM Initializing Java Language Server 1.28.0.202309280239'}
They appear to be extracting the JDT-LS runtime directly out of the vsix we publish. For 1.23.0 (JDT-LS 1.28.0) we used the 4.29 release, so org.eclipse.jdt.launching 3.20.100.v20230814-1810
.
I've expanded https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u392-b08/OpenJDK8U-jdk_x64_linux_hotspot_8u392b08.tar.gz in my /usr/lib/jvm/
folder beside all other installs, restarted my IDE (latest I-Build from 4.30) and didn't see an issue in the log and could see the newly added folder listed in Java > Installed JREs
preference page.
I would recommend anyone who can reproduce this issue to try reproducing it from a recent i-Build of Eclipse JDT or of JDT-LS master branch (which IIRC is using the I-Build).
is /usr/lib/jvm/java-8-openjdk-amd64 a symbolic link ?
I actually just uninstalled the system level jdk-8 installed at the above path (sudo apt remove openjdk-8-*), before reading your comment, so unfortunately, I can't confirm. However, there are other system-level jdks installed and:
username@machinename:/path/to/dir$ ls -la /usr/lib/jvm/
total 48
drwxr-xr-x 7 root root 4096 Nov 20 19:24 .
drwxr-xr-x 143 root root 12288 Nov 20 19:27 ..
-rw-r--r-- 1 root root 2047 Aug 24 22:32 .java-1.11.0-openjdk-amd64.jinfo
-rw-r--r-- 1 root root 1773 Aug 24 22:55 .java-1.17.0-openjdk-amd64.jinfo
-rw-r--r-- 1 root root 1997 Oct 11 10:29 .msopenjdk-11-amd64.jinfo
lrwxrwxrwx 1 root root 25 Jul 17 2019 default-java -> java-1.11.0-openjdk-amd64
lrwxrwxrwx 1 root root 21 Jan 20 2023 java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
lrwxrwxrwx 1 root root 21 Aug 24 22:55 java-1.17.0-openjdk-amd64 -> java-17-openjdk-amd64
drwxr-xr-x 9 root root 4096 Oct 26 00:49 java-11-openjdk-amd64
drwxr-xr-x 9 root root 4096 Oct 26 00:49 java-17-openjdk-amd64
drwxr-xr-x 9 root root 4096 Nov 20 19:24 msopenjdk-11-amd64
drwxr-xr-x 2 root root 4096 Oct 26 00:49 openjdk-11
drwxr-xr-x 2 root root 4096 Oct 26 00:49 openjdk-17
The above reported issue still persists after uninstalling the system level jdk-8.
Can you try adding the following as a system property to the JDT-LS launch : -DDetectVMInstallationsJob.disabled=true.
I added the above as well, and the same issue still persists.
As pointed out by rightly by @rgrunber, I download the vsix from https://github.com/redhat-developer/vscode-java/releases/download/v1.23.0/java@linux-x64-1.23.0.vsix and use the jdtls packaged in it. Kindly let me know if I should use a more recent vsix package and I can get back to you with results on the updated version.
The JDK that is failing, path/to/downloaded/binaries/jdks/openlogic-openjdk-8u392-b08-linux-x64/bin/java
, isn't anywhere in /usr/lib/jvm/
though from what I can see. However, as long as that binary has the execute bit set on the "other" group, or if the user that starts the client (that starts JDT-LS) is part of the group/is the user that owns the binary, then it should work. If the permissions on that binary really are ---x------
then you'll need to confirm JDT-LS is launched as USERNAME
. You could do that as followed :
When JDT-LS is started, can you run jps -l
to get it's PID :
$ jps -l
23490 jdk.jcmd/sun.tools.jps.Jps
23177 /PATH/TO/JDT-LS/INSTALL/server/plugins/org.eclipse.equinox.launcher_1.6.600.v20231012-1237.jar
$
$ ps -o user= 23177
rgrunber
You'd want that to match the user that owns the binary.
I am trying to add JDK-17 and JDK-8 runtimes support to multilspy. While it works perfectly with JDK-17, and JDK-8 on windows, when I try to run the same with JDK-8 on Linux, Eclipse crashes saying there are permission errors. I have ensured the permissions for the JDK8 binary files are the same as those for the JDK17 binaries. Further, I have tried with JDK 8 packages downloaded from https://builds.openlogic.com/downloadJDK/openlogic-openjdk/8u392-b08/openlogic-openjdk-8u392-b08-linux-x64.tar.gz, https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u392-b08/OpenJDK8U-jdk_x64_linux_hotspot_8u392b08.tar.gz and https://www.oracle.com/java/technologies/javase/javase8u211-later-archive-downloads.html#license-lightbox. I am able to run the java binary from all of the above packages from my shell, however the permission errors arise with all of the packages. The full client<->server communication trace is available at https://pastebin.com/45xSNiqH. The server is launched with JDK17, and I pass the path to JDK17 and JDK8 through the settings.java.configuration.runtimes configuration option.
Also, note that I did not supply the path of
/usr/lib/jvm/java-8-openjdk-amd64
in the runtimes key above, and it was instead found automatically by the server (see logs below).I get the following errors in window/logMessage:
Error message from server to client:
stderr output of jdt.ls: