What happened?
On a Linux remote-development host with glibc 2.26 (Amazon Linux 2), the extension's downloaded helper binaries cannot be loaded, so gradle-language-server never starts:
initializing server gradle-language-server, id 11: server shut down
-- stderr --
.../work/java/bin/v6.8.26/gradle-lsp-bridge: /lib64/libm.so.6: version `GLIBC_2.29' not found
.../work/java/bin/v6.8.26/gradle-lsp-bridge: /lib64/libc.so.6: version `GLIBC_2.28' not found
.../work/java/bin/v6.8.26/gradle-lsp-bridge: /lib64/libc.so.6: version `GLIBC_2.34' not found
Both v6.8.26 linux-x86_64 assets need up to GLIBC_2.34, which is what the ubuntu-22.04 release runner provides:
$ objdump -T gradle-lsp-bridge | grep -o 'GLIBC_[0-9.]*' | sort -uV | tail -1
GLIBC_2.34
Three things that make this worse than it first looks:
java-lsp-proxy has the same floor, so classpath queries, main-class resolution and debug session start are broken too. That failure is silent: no "server shut down", just features that never work.- v6.8.23 assets have the same floor, so pinning an older extension version does not help.
- Zed itself works fine on this host because its remote server is statically linked. So Zed supports the host, but the Java extension cannot run there.
Repro: install the extension on any Linux host whose glibc is older than the release runner's and open a Gradle build file.
Workaround for anyone else hitting this: build the two binaries from the matching release tag with --target x86_64-unknown-linux-musl and put them in work/java/bin/ (the unversioned override path from the README). The static build works: initialize returns real capabilities and gradle-server connects on the task pipe.
What did you expect to happen?
The Gradle language server starts on any host Zed itself supports. Zed's remote server is static musl, so the extension's helper binaries should not inherit a glibc floor from the release runner image.
Suggested fix: build the two Linux release targets in release-proxy.yml as *-unknown-linux-musl instead of *-unknown-linux-gnu. Both binaries are pure Rust with no C dependencies, Rust ships a self-contained musl libc so the runners need no extra packages, and the asset names do not change, so nothing on the download path changes. A CI step that fails on any dynamically linked Linux binary would keep the floor from coming back. Happy to send a PR if you would like one.
Environment
Zed: remote server 1.16.2 (stable); client
Platform: remote host Amazon Linux 2 (glibc 2.26) x86_64; client
Java extension: v6.8.26
Java: Corretto 17.0.20 on PATH, plus extension-downloaded Corretto 25.0.4.7.1 for JDTLS
What happened?
On a Linux remote-development host with glibc 2.26 (Amazon Linux 2), the extension's downloaded helper binaries cannot be loaded, so
gradle-language-servernever starts:Both v6.8.26
linux-x86_64assets need up toGLIBC_2.34, which is what theubuntu-22.04release runner provides:Three things that make this worse than it first looks:
java-lsp-proxyhas the same floor, so classpath queries, main-class resolution and debug session start are broken too. That failure is silent: no "server shut down", just features that never work.Repro: install the extension on any Linux host whose glibc is older than the release runner's and open a Gradle build file.
Workaround for anyone else hitting this: build the two binaries from the matching release tag with
--target x86_64-unknown-linux-musland put them inwork/java/bin/(the unversioned override path from the README). The static build works:initializereturns real capabilities andgradle-serverconnects on the task pipe.What did you expect to happen?
The Gradle language server starts on any host Zed itself supports. Zed's remote server is static musl, so the extension's helper binaries should not inherit a glibc floor from the release runner image.
Suggested fix: build the two Linux release targets in
release-proxy.ymlas*-unknown-linux-muslinstead of*-unknown-linux-gnu. Both binaries are pure Rust with no C dependencies, Rust ships a self-contained musl libc so the runners need no extra packages, and the asset names do not change, so nothing on the download path changes. A CI step that fails on any dynamically linked Linux binary would keep the floor from coming back. Happy to send a PR if you would like one.Environment
Zed: remote server 1.16.2 (stable); client
Platform: remote host Amazon Linux 2 (glibc 2.26) x86_64; client
Java extension: v6.8.26
Java: Corretto 17.0.20 on PATH, plus extension-downloaded Corretto 25.0.4.7.1 for JDTLS