Zed settings for `lsp.jdtls.settings.classpath` seem to be ignored

[dpapathanasiou]

Relevance Confirmation

• I confirmed that this is not an issue with the Eclipse JDT Language Server itself

What happened?

I'm going through the simple calculator example in CUP, and I've downloaded the corresponding jar files in /usr/local/java-cup/.

Using them in the terminal works as expected, but Zed complains that The import java_cup.runtime cannot be resolved (268435846) despite my having this block in my ~/.config/zed/settings.json file:

  "lsp": {
    "jdtls": {
      "settings": {
        "classpath": "/usr/local/java-cup/java-cup-11b.jar:/usr/local/java-cup/java-cup-11b-runtime.jar"
      },
      "initialization_options": {}
    }
  }

I have confirmed that jdtls is running, just lacking the classpath I'm giving it:

$ ps -ef | grep jdtls         
  501 10820 10571   0  5:33PM ??         0:04.89 -Declipse.application=org.eclipse.jdt.ls.core.id1 -Dosgi.bundles.defaultStartLevel=4 -Declipse.product=org.eclipse.jdt.ls.core.product -Dosgi.checkConfiguration=true -Dosgi.sharedConfiguration.area=/Users/denis/Library/Application Support/Zed/extensions/work/java/jdtls/jdt-language-server-1.44.0-202501221502/config_mac -Dosgi.sharedConfiguration.area.readOnly=true -Dosgi.configuration.cascaded=true -Xms1G --add-modules=ALL-SYSTEM --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED -jar /Users/denis/Library/Application Support/Zed/extensions/work/java/jdtls/jdt-language-server-1.44.0-202501221502/plugins/org.eclipse.equinox.launcher_1.6.900.v20240613-2009.jar -data /var/folders/c0/3v25x0x932ncxmxksyjky7100000gn/T/jdtls-04df9577c2c8bc17736b0ae73d92dcd9c74e6311

I am running the latest version of this extension, on Zed 0.170.2 (43b8788b290346c856820544dc70d1d13a235516), on macos.

What did you expect to happen?

If the classpath with those CUP jars was being passed to jdtls correctly, I should not be seeing warnings like The import java_cup.runtime cannot be resolved (268435846)

[valentinegb]

From what I can find, it seems like JDTLS just doesn't pay attention to any effort to set the classpath ¯\_(^_^;)_/¯
I'm going to remove the classpath setting since it doesn't work and it doesn't seem like there's a way to make it work, but I think you can get JDTLS to do what you want according to this:

Wow, thank you so much, that actually worked! For anyone who may come across this in the future, after reading section 3.4 of the documentation linked above, I had to make ~/.cache/jdtls-workspace/my_project_directory/.classpath look like this: (although the tildes are replaced with my home directory path in the actual file)

<?xml version="1.0" encoding="UTF-8"?>

<classpath>

	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

	<classpathentry kind="src" path="_"/>

	<classpathentry kind="lib" path="~/.m2/repository/org/junit/platform/junit-platform-console-standalone/1.8.2/junit-platform-console-standalone-1.8.2.jar" sourcepath="~/.m2/repository/org/junit/platform/junit-platform-console-standalone/1.8.2/junit-platform-console-standalone-1.8.2-sources.jar"/>

	<classpathentry kind="output" path="bin"/>

</classpath>

Basically, this is the .classpath file in the directory that jdtls automatically creates every time I create a new project. Normally, the file will look like the above except for the third classpathentry line (kind="lib"), which is the only one I had to add. Originally, I actually moved the junit-platform-console-standalone-1.8.2.jar file into ~/.cache/jdtls-workspace/my_project_directory/ and only added the path attribute as path="junit-platform-console-standalone-1.8.2.jar" since it was in the same directory as the .classpath file. But then, when I reopened the .classpath file, I noticed that jdtls automatically edited it and added the sourcepath attribute. So, instead of having to copy the junit-platform-console-standalone-1.8.2.jar file into each workspace directory I have, I instead changed the path attribute to point to another place that contained the same .jar file. All this to say that I'm pretty sure you just need to specify the path to a junit-platform-console-standalone-1.8.2.jar file in the path attribute and then jdtls will hopefully take care of the rest.

However, upon further testing, I noticed that if I tried editing the .classpath files of multiple projects and then opened up a JUnit test file in one project and then another, jdtls would for some reason remove the line I added to the .classpath file, then causing all the usual import errors to pop up again in Neovim. I have absolutely no idea why jdtls decides to overwrite the .classpath file of another project when I open up a file, but I'm not even going to try to understand at this point.

Thanks so much again for all your help!

Originally posted by @plt3 in #13