JDT.LS binary download does not honour VS Code http.proxy setting in corporate networks

[chirag127]

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

1. In a corporate environment, set:

   "http.proxy": "http://proxy.corp.example.com:8080",
   "http.proxyStrictSSL": false

2. Install the extension on a machine that has no prior JDT.LS installation.
3. Open a Java file. The status bar shows "Downloading Java support..." indefinitely.
4. No error appears; the Output → Java channel shows a TCP timeout to download.jboss.org or 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 client

Environment

• OS: Windows 11 Enterprise 10.0.26200 (mandatory corporate proxy, no direct internet)
• VS Code: 1.89+
• Extension: redhat.java latest

[wenytang-ms]

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.vsix to 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 launcher
• extension/jre/... → a full embedded Temurin JDK 21

At runtime the extension just loads the server from that local folder (javaServerStarter.ts):

const serverHome = process.env.JDT_LS_PATH || path.resolve(__dirname, '../server');

There's no Node HTTP client fetching the server, no download.jboss.org call, 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-agent don't apply. Instead, JDT.LS reads the standard JVM proxy system properties at startup and wires them into Eclipse's IProxyService (org.eclipse.core.net), which is what its networking stack consults. You set them via java.jdt.ls.vmargs:

"java.jdt.ls.vmargs": "-Dhttps.proxyHost=proxy.corp.example.com -Dhttps.proxyPort=8080 -Dhttps.proxyUser=USER -Dhttps.proxyPassword=PASS"

One important detail from the code (JavaLanguageServerPlugin.java): the manual/authenticated proxy path only kicks in when *.proxyUser is set. If you pass only host + port, it falls back to the OS-native proxy provider. So for an authenticated corporate proxy, include proxyUser/proxyPassword too. (http. prefix works the same way, and https.nonProxyHosts handles 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. 👍