Repository navigation
JDT.LS binary download does not honour VS Code http.proxy setting in corporate networks #4452
Description
Problem
On first install (or when the extension downloads a JDT.LS update), the download fails silently in corporate environments that require an authenticated HTTPS proxy. VS Code exposes the proxy via http.proxy and http.proxyAuthorization settings, and also via HTTPS_PROXY / HTTP_PROXY environment variables injected into the extension host. However, the extension's download logic (in src/extension.ts and the download utility) does not read these and passes no proxy configuration to its HTTP client.
Steps to Reproduce
- In a corporate environment, set:
"http.proxy": "http://proxy.corp.example.com:8080", "http.proxyStrictSSL": false
- Install the extension on a machine that has no prior JDT.LS installation.
- Open a Java file. The status bar shows "Downloading Java support..." indefinitely.
- No error appears; the Output → Java channel shows a TCP timeout to
download.jboss.orgor the GitHub releases CDN.
Expected Behaviour
The extension should detect the proxy from vscode.workspace.getConfiguration('http').get('proxy') or process.env.HTTPS_PROXY and configure its HTTP download agent accordingly (e.g., via https-proxy-agent or equivalent).
Workaround (not acceptable)
Users currently have to pre-download JDT.LS manually, which is not discoverable and breaks on updates.
Proposed Fix
import HttpsProxyAgent from 'https-proxy-agent';
const proxyUrl = vscode.workspace.getConfiguration('http').get<string>('proxy')
?? process.env.HTTPS_PROXY ?? process.env.HTTP_PROXY;
const agent = proxyUrl ? new HttpsProxyAgent(proxyUrl) : undefined;
// Pass agent to node-fetch / got / axios download clientEnvironment
- OS: Windows 11 Enterprise 10.0.26200 (mandatory corporate proxy, no direct internet)
- VS Code: 1.89+
- Extension: redhat.java latest
Activity
wenytang-ms commentedon Jul 3, 2026
Hey, thanks for the report! I dug into this though, and the premise doesn't quite match how the extension actually works. 🙂
JDT.LS isn't downloaded at runtime — it ships inside the VSIX.
I unzipped the latest
redhat.java-1.55.0-win32-x64.vsixto double-check, and both the language server and a JRE are bundled:extension/server/plugins/→ 114 jars, including the JDT.LS core and the Equinox launcherextension/jre/...→ a full embedded Temurin JDK 21At runtime the extension just loads the server from that local folder (
javaServerStarter.ts):There's no Node HTTP client fetching the server, no
download.jboss.orgcall, and no "Downloading Java support..." status bar message in the code — so the repro steps describe a code path that doesn't exist. Server updates ship as new VSIX releases.How proxying actually works here: the network calls that happen at runtime (Maven/Gradle source downloads, etc.) run inside the JDT.LS JVM process, not Node — so
http.proxy/https-proxy-agentdon't apply. Instead, JDT.LS reads the standard JVM proxy system properties at startup and wires them into Eclipse'sIProxyService(org.eclipse.core.net), which is what its networking stack consults. You set them viajava.jdt.ls.vmargs:One important detail from the code (
JavaLanguageServerPlugin.java): the manual/authenticated proxy path only kicks in when*.proxyUseris set. If you pass only host + port, it falls back to the OS-native proxy provider. So for an authenticated corporate proxy, includeproxyUser/proxyPasswordtoo. (http.prefix works the same way, andhttps.nonProxyHostshandles bypass lists.)If you're actually seeing a hang on first launch behind a proxy, please grab the Output → Language Support for Java log and share where it's stuck — happy to help track down the real cause. 👍