Allow customization of JDTLS -data directory / stop polluting user %APPDATA% root directory

[a1730]

Relevance Confirmation

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

What happened?

After opening some java files in different, then I started seeing multiple jdtls-* directories in my %appdata% folder on Windows platform.

Currently, it seems the Zed Java extension hardcodes the language server's workspace storage directory, explicitly passing a hardcoded -data argument pointing directly to the user's root %APPDATA% (on Windows) or home directories (e.g., ~/.config).
Because it appends a cryptographic hash derived from the workspace path (jdtls-<workspace_hash>), it drops highly visible, messy cache folders directly into the main configuration directories. For example, my server logs show the extension explicitly executing:

Command-line arguments: -data C:\Users\<user>\AppData\Roaming/jdtls-dfa4c3290a450df4ed4d264e4d87193daecb1b3b

This behavior overrides standard initialization_options (like passing a custom "data" block in settings.json), because command-line flags always take priority in the Eclipse JDTLS binary.
Per Eclipse JDTLS specifications:

"If the option is not explicitly set, jdtls stores the data in a sub-folder within tempdir. The sub-folder name is derived from cwd."

By forcing the -data CLI flag, the extension strips away JDTLS's native ability to use the system temp directory, creating a configuration and cleanup debt for users who want a clean %appdata% directory.

Proposed Solution

Modify the extension's pre-compiled launcher code (the WASM/Rust wrapper) to check for a custom data directory configuration, or omit the hardcoded -data flag entirely if a user defines it.
Ideally, expose a configuration setting under lsp.jdtls.settings or honor a top-level override string, such as (which I tried):

"lsp": {
  "jdtls": {
    "settings": {
      "data_directory": "C:/Opt/zed-jdtls" 
    }
  }
}

If no override is provided, consider letting JDTLS fall back to its native behavior of using the system's tempdir instead of polluting the global configuration root.

Additional Context

Currently, the only workaround is using Windows Directory Junctions (mklink /J) on a per-project hash basis to intercept the hardcoded writes, which is highly brittle and high-maintenance. [1]

[1] https://medium.com

What did you expect to happen?

I expect Zed to use my configured jdtls data directory, or let jdtls do its thing.

Environment

Zed: 1.15.0
Commit: e17dc4f9d50db73a458b64dcce50ecd4878b98a3
Platform: Windows 11 Version 24H2
Java: OpenJDK v26.0.1