Let user provide JDTLS, Lombok and debugger URL for download

[tartarughina]

It might be cool for the user to be able to override the required version of jdtls in the settings. In case the latest isn't compatible for some reason or the tags don't exactly match the filenames or eclipse dumps jdk8 support or...

Originally posted by @Arthurm1 in #118 (comment)

[himicoswilson]

#132

[Arthurm1]

@himicoswilson I was thinking that only the version could be entered in the settings, not the whole url. Just to make it as simple as possible for users if the latest version of one of these isn't compatible for some reason.

Are there multiple download sites for JDTLS, Lombok, debugger (I don't know)? If not, supplying the whole url seems like overkill. That might just be me though.

[himicoswilson]

@Arthurm1 Good point, keeping it simple is ideal.
The reason I’m leaning toward configuring the full URL (instead of just the version) is for users in regions or network environments where some domains/CDNs are blocked, slow, or need to go through mirrors / internal proxies.
Having the full URL configurable gives them more control and makes it easier to switch to an accessible source without us changing the code. For users with normal network conditions it’s basically transparent, but for restricted environments it’s essential.

[playdohface]

I agree that pinning the versions via URLs is probably a better solution than adding the version number and downloading from a fixed repository.
I wonder if it might even make sense to just let the user just point at a local file and have them manage it manually if they need their versions pinned for some reason - correct me if I am wrong but having to pin jdtls or the lombok-plugin or java-debug to a version less than the latest one should be a fairly niche use-case unless they introduce some bad regressions.
And the other reason why someone would want this is because they don't want the extension downloading things without asking (or at all), because of metered connections or security concerns. And in the latter case, they probably want to manage the files themselves anyway.

[tartarughina]

I agree with @playdohface.

If the user wants to provide a specific version of JDTLS, Lombok or debugger, it should be via a local path.
Anything that requires the extension to download something is prone to fail as:

• is the file uncompressed or compressed? If the latter, which compression?
• is the downloaded file following the same structure that we expect from the location we are downloading from?

The path approach is also much cleaner to implement and it doesn't add complexity to the extension.
Not only it is better for us to maintain but it also provides more control to the user which will manage everything by himself.

It could also be seen as an improvement over having jdtls set in the PATH. In this way you could really have custom java settings per project rather than having to switch back and forth things in your zshrc or whatever Windows uses to manage the PATH.

[playdohface]

This is how I would envision this to work:
So if we land #132 giving us update_check_mode the next thing would be to add three config options:
lombok_plugin_jar, java_debug_jar, jdtls_launcher (not sure if those are the ideal names but something along those lines). If they are set, the plugin would always try to use them (they should be absolute local paths) regardless of update_check_mode, and if they are not valid this should be the user's problem (but we should make sure to document it clearly to make that less likely).

This way, the user has all the granularity they could want: most people should be fine with the default, people who are sensitive to unexpected downloads use update_check_mode: once, and people who need to do fancy stuff with one or more components can just bring their own.

[himicoswilson]

@playdohface I agree with your proposal — it gives users exactly the level of flexibility they might want. I just have one concern: I’m not sure whether using absolute paths is currently possible in Zed’s extension environment.

From what I understand, Zed extensions run inside a WASM sandbox, and the API doesn’t allow extensions to read arbitrary local filesystem paths. The extension can’t open something like /path/to/lombok.jar directly.

Because of this, options like lombok_plugin_jar, java_debug_jar, or jdtls_launcher sound great, but they might not be feasible unless Zed adds new capabilities.

If I’m missing something, I’m very happy to learn more — just wanted to bring up this potential limitation before we go further.

[playdohface]

I think receiving and passing on absolute paths from config is fine, we just can not read or write from/to them. So if the user gives us /foo/bar/my_lombok.jar we can pass this on to JDTLS and JDTLS can use it (as it is ultimately launched from Zed and so has it's privileges), but we can't check whether there is actually a file there or modify/delete it from the extension code.

So "black-box" paths from configuration options are fine, we are essentially just passing them on as strings to Zed.

By the way, our proxy is launched from Zed and we can theoretically escape the sandbox with it if we really have to, but we definitely should not do that unless there is a really good reason to.