Feature request: expose Eclipse classpath variables (kind="var") via configuration

[levanliu]

Feature request

Expose Eclipse classpath variables so that .classpath entries of kind="var" resolve in jdt.ls the same way they do in the Eclipse IDE.

Background

jdt.ls is built on Eclipse JDT Core, which already fully supports classpath variables:

• They are persisted as instance preferences (org.eclipse.jdt.core.classpathVariable.<NAME>=<path>).
• They can be set programmatically via JavaCore.setClasspathVariable(name, path, monitor) / JavaCore.setClasspathVariables(...).

The desktop Eclipse IDE exposes these through Preferences → Java → Build Path → Classpath Variables.
jdt.ls (and the VS Code Java client) currently exposes no way to configure them — neither via initializationOptions, nor via a workspace/didChangeConfiguration setting.

Problem

Large, long-lived Eclipse projects (not driven by Maven/Gradle) legitimately use .classpath entries such as:

<classpathentry kind="var" path="WORKSPACE/IDL/IdlInterfaces.jar"/>
<classpathentry kind="var" path="UNO_JAVA_DIR/libreoffice.jar"/>

When such a project is opened in VS Code, jdt.ls reports:

Unbound classpath variable: 'WORKSPACE/IDL/IdlInterfaces.jar' in project '...'
The project cannot be built until build path errors are resolved

All dependencies behind those variables are left unresolved, which cascades into broken LSP features (completion, navigation, diagnostics) for the whole project graph.

Proposed solution

Allow classpath variables to be supplied through the standard configuration channels and apply them via JavaCore.setClasspathVariables(...):

• On startup, read them from initializationOptions.settings (e.g. a java.configuration.classpathVariables / java.classpath.variables map of name → absolute path).
• On workspace/didChangeConfiguration, update them the same way (calling JavaCore.setClasspathVariable for added/changed entries).

Example (client settings):

"java.classpath.variables": {
  "WORKSPACE": "/abs/path/to/workspace",
  "UNO_JAVA_DIR": "/abs/path/to/uno-java"
}

The corresponding VS Code client mapping would live in redhat-developer/vscode-java, but the core capability (reading the setting and calling JavaCore.setClasspathVariable) belongs here in jdt.ls.

Why this is worth having

• It removes the need for the undocumented .prefs-seeding hack.
• It brings jdt.ls to parity with the Eclipse IDE for a mechanism JDT Core already supports.
• The change is small and localized to preference/settings handling — no new build-system integration required.

Environment

• jdt.ls: 1.59.0.202606241329 (bundled with redhat.java)
• VS Code + redhat.java (Language Support for Java)
• JDK: 21 / 25
• OS: Linux

Alternatives considered

• Rewriting .classpath kind="var" entries to absolute kind="lib" paths — pollutes shared, version-controlled repository files and is not portable across machines.
• Regenerating .classpath from the build metadata — larger maintenance surface and still not an upstream fix.

Happy to help test a patch.