Use our own fork of java-debug

[playdohface]

Closes #67

Zed and java-debug appear to disagree in their interpretations of the DAP-spec. Since we have no control over the release cycle of java-debug and indeed whether they accept the change to begin with, and the Zed team declines to adopt a more lenient stance in their interpretation of the spec, we must run our own fork of java-debug.

I've created a fork with the required fixes and a release for us to use here: https://github.com/playdohface/java-debug

This PR will make the extension download the forked release once if not installed yet, and then use it indefinitely. When the underlying issues are resolved either from Zeds side (zed-industries/zed#37080) or java-debug merges our changes and makes a new release (microsoft/java-debug#609) we can switch back our code to use the latest official release for java-debug.

[tartarughina]

We could adopt the same approach for the language server itself.
jdtls is currently returning -1 when providing the active param of a function with zero parameters.
Replacing the fallback return of -1 with the actual number of parameters makes things work.

Ref: eclipse-jdtls/eclipse.jdt.ls#2434

[MrSubidubi]

Thanks for looking into it! Will quickly check back with some folks internally on this, but other than that, looks good!

[playdohface]

We could adopt the same approach for the language server itself. jdtls is currently returning -1 when providing the active param of a function with zero parameters. Replacing the fallback return of -1 with the actual number of parameters makes things work.

Ref: eclipse-jdtls/eclipse.jdt.ls#2434

@tartarughina We could do that, but I don't think the situation with JDTLS is quite the same. For one, their release-cycle is 4 weeks and so if there are problems in JDTLS, and especially ones that are clear-cut in terms of the LSP-spec, the chances of simply upstreaming a fix in a reasonable time-frame are quite high. It's just that the JDTLS team generally writes against more lenient client implementations (VSCode being the de-facto reference implementation) and they will have little urgency to fix problems that only surface in Zed.
But if there are fixes for JDTLS available that significantly improve the experience and the JDTLS-team does not want to, or is very slow at upstreaming them, we always have that choice. But I think first we need to actually develop the fixes...

[tartarughina]

But I think first we need to actually develop the fixes...

You mean on Zed side or forking JDTLS? If you're referring to the latter I've been running a version with the proposed changes for more than two months.
I haven't published the changes and created a pull request on JDTLS as I haven't tested the behavior that VS Code would have. But I could work on that later this week.

[playdohface]

@tartarughina nice! Maybe let's open an issue about that in here?

[DeityLamb]

We could adopt the same approach for the language server itself. jdtls is currently returning -1 when providing the active param of a function with zero parameters. Replacing the fallback return of -1 with the actual number of parameters makes things work.

Ref: eclipse-jdtls/eclipse.jdt.ls#2434

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

In general, I think a similar approach could also be applied to DAP, but in that case, we’d have to create a proxy wrapper there as well to fit our needs

In the long run, this would greatly simplify solving issues related to zed/jdtls/java-dap, where none of the parties are interested in fixing them quickly

But that’s not really related to the current PR :)
Honestly, I’m fine with the current fork-based solution as well

[playdohface]

Let's move the discussion about forking JDTLS to #103 . @MrSubidubi mentioned on discord that the zed team might move the fork to a zed-industries owned repo, which would make the whole solution a bit more trustworthy. From the java-debug side there is crickets so far.