Use our own fork of jdtls

[tartarughina]

Relevance Confirmation

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

What happened?

JDTLS and Zed implement the LSP specifications differently when returning the active parameter of a function. JDTLS returns -1, while Zed expects 0, as the expected value is represented by the u64 type.

More details, along with a proposed solution, can be found here: eclipse-jdtls/eclipse.jdt.ls#2434

This discrepancy causes Zed to fail in parsing and properly handling the message from the language server, resulting in no documentation or hints being displayed for functions with zero parameters on hover.

What did you expect to happen?

I expect that JDTLS will eventually align with the specifications, enabling documentation and hints for functions without parameters. While waiting for JDTLS to implement this change, we could use our own fork by applying the proposed solution found at eclipse-jdtls/eclipse.jdt.ls#2434.

This solution could also be submitted as a pull request to JDTLS. If merged, the workaround could be removed.

Environment

Zed: v0.209.2 (Zed Preview)
OS: macOS 15.7.1
Memory: 16 GiB
Architecture: x86_64

[playdohface]

Just to keep the info all in one place, @DeityLamb suggested we can also work around issues in JDTLS with our proxy:

We could actually fix this right here
https://github.com/zed-extensions/java/blob/main/src/proxy.mjs#L34
So we wouldn’t have to fork jdtls itself
just filter the request we need and send back the response with the same id manually
That would be much faster to implement

Personally I'm torn which approach I would prefer. The proxy itself is a workaround for the fact we can't send LSP-messages from within the extension natively, I'm hopeful for a resolution within Zed, though the time frame on that is not clear.
If we start fixing up JDTLS responses in the proxy, we can probably solve a bunch of problems quickly, but the solutions will ultimately be brittle. It also means we are somewhat marrying the proxy until we find the time to upstream everything we need fixed, in JDTLS and Zed alike. Which I guess is fine, as long as it works...

@tartarughina do we have a working implementation of the mentioned solution for the JDTLS -bug that we can link here?

[DeityLamb]

Actually, I initially designed this functionality with the idea of implementing "go to" for decompiled files #44
I might be wrong, but it seems that in this case we need to intercept LSP requests, and that’s apparently how it’s implemented in the VSCode Java extension

So either way, we’ll end up relying on a proxy or waiting for this functionality to be added to Zed

I personally like the idea of forking jdtls / dap, it’s a cleaner approach, but maintaining it would be quite hard 🤷‍♂️

[tartarughina]

Here's the commit to the forked version of jdtls implementing the mentioned solution.

While we wait for the changes on the extension ( I'll be working on it this weekend ) you can try the forked version.

Steps to download, build and link forked version of jdtls

1. Clone the repository
2. Build the project via ./mvnw clean verify -U -DskipTests=true
   • The expected min java version is 21
   • This command builds the server into the ./org.eclipse.jdt.ls.product/target/repository folder
3. Update Zed configs like so, adjust the path to where you cloned the repo:

   "lsp": {
     "jdtls": {
       "binary": {
         "path": "/Users/tartarughina/Develop/eclipse.jdt.ls/org.eclipse.jdt.ls.product/target/repository/bin/jdtls"
       }
     }
   }

   • The absolute path is required as ~ is not expanded

[tartarughina]

I've also opened a PR on jdt.ls itself to officially adopt the changes eclipse-jdtls/eclipse.jdt.ls#3580

[tartarughina]

The PR on eclipse.jdt.ls has been merged, we no longer need the forked version