JDT-MCP unterstützt --release 25 (noch) nicht — Zwang zum Fallback auf shell-mvn #82

Open

opened 2026-07-20 12:48:48 +00:00 by hauschel.fred · 1 comment

hauschel.fred commented

2026-07-20 12:48:48 +00:00

Collaborator

Beschreibung

Projekte, die mit --release 25 gebaut werden (Java 25 als Compiler-Release), können mit JDT-MCP nicht gebaut/refactored werden. Betroffene Projekte müssen deshalb auf shell-mvn (default JDK 25) ausweichen, statt die JDT-MCP-Tools zu nutzen.

Konkret aufgetreten im Projekt arknet (io.kogn.rdf ist Java-25-gebaut). Dessen CLAUDE.md hält als Betriebsregel fest:

Bauen/Testen: shell-mvn (default JDK 25); JDT-MCP kann --release 25 (noch) nicht

Abgrenzung

Nicht identisch mit #55 — #55 betrifft die Java-Version des Plugins selbst (MANIFEST JavaSE-17 vs. Anforderung Java 21+). Hier geht es um die Compiler-Release-Stufe der Ziel-Projekte (--release 25), die JDT-MCP beim Import/Build nicht verarbeiten kann.

Auswirkung

jdt_maven_build / jdt_import_project / Refactorings auf Java-25---release-Projekten nicht nutzbar
Erzwingt Fallback auf shell-mvn, wodurch der Mehrwert der JDT-MCP-Tools (Refactorings, Compilation-Errors, Referenz-Suche) für diese Projekte entfällt

Erwartetes Verhalten

JDT-MCP kann Projekte mit --release 25 importieren, bauen und refactoren.

Umgebung

Betroffenes Projekt: arknet (io.kogn.rdf, Java 25)
Default JDK der Maschine: 25

## Beschreibung Projekte, die mit `--release 25` gebaut werden (Java 25 als Compiler-Release), können mit JDT-MCP nicht gebaut/refactored werden. Betroffene Projekte müssen deshalb auf shell-`mvn` (default JDK 25) ausweichen, statt die JDT-MCP-Tools zu nutzen. Konkret aufgetreten im Projekt **arknet** (`io.kogn.rdf` ist Java-25-gebaut). Dessen `CLAUDE.md` hält als Betriebsregel fest: > Bauen/Testen: shell-`mvn` (default JDK 25); JDT-MCP kann `--release 25` (noch) nicht ## Abgrenzung Nicht identisch mit #55 — #55 betrifft die **Java-Version des Plugins selbst** (MANIFEST `JavaSE-17` vs. Anforderung Java 21+). Hier geht es um die **Compiler-Release-Stufe der Ziel-Projekte** (`--release 25`), die JDT-MCP beim Import/Build nicht verarbeiten kann. ## Auswirkung - `jdt_maven_build` / `jdt_import_project` / Refactorings auf Java-25-`--release`-Projekten nicht nutzbar - Erzwingt Fallback auf shell-`mvn`, wodurch der Mehrwert der JDT-MCP-Tools (Refactorings, Compilation-Errors, Referenz-Suche) für diese Projekte entfällt ## Erwartetes Verhalten JDT-MCP kann Projekte mit `--release 25` importieren, bauen und refactoren. ## Umgebung - Betroffenes Projekt: arknet (`io.kogn.rdf`, Java 25) - Default JDK der Maschine: 25

hauschel.fred referenced this issue

2026-09-07 16:23:44 +00:00

Java-Version-Inkonsistenz: MANIFEST JavaSE-17 vs. Anforderung Java 21+ #55

hauschel.fred commented

2026-09-07 16:23:57 +00:00

Author

Collaborator

Triage 2026-09-07: Ursache unbekannt, Reproduktion nötig

Das Issue beschreibt eine Betriebsregel, aber keinen konkreten Fehler. Was ich auf main sehe:

Target-Platform ist Eclipse 2025-12, die Java 25 nativ unterstützt. JDT selbst ist also nicht die Grenze.
ProjectImporter setzt keine Compiler-Compliance aus maven.compiler.release/<release>, sondern verlässt sich auf den Default-JRE_CONTAINER (Zeilen 248, 308, 756) und die Workspace-Default-Optionen. Welche Compliance dabei effektiv gilt, hängt davon ab, mit welchem JDK der Launcher gestartet wurde (JAVA_HOME, sonst java im PATH).
Ein Test gegen arknet (Java 25) am 2026-09-07 konnte importieren und Referenzen suchen; die Probleme dort lagen bei Test-Output-Ordnern und dem JUnit-Loader (#71), nicht bei --release 25.

Nächster Schritt: Mit einem --release 25-Modul reproduzieren und die konkrete Fehlermeldung hier ablegen (jdt_get_compilation_errors und jdt_get_project_structure → compliance). Wahrscheinlicher Fix: Compliance beim Import aus der POM übernehmen.

## Triage 2026-09-07: Ursache unbekannt, Reproduktion nötig Das Issue beschreibt eine Betriebsregel, aber keinen konkreten Fehler. Was ich auf `main` sehe: - Target-Platform ist Eclipse 2025-12, die Java 25 nativ unterstützt. JDT selbst ist also nicht die Grenze. - `ProjectImporter` setzt **keine** Compiler-Compliance aus `maven.compiler.release`/`<release>`, sondern verlässt sich auf den Default-`JRE_CONTAINER` (Zeilen 248, 308, 756) und die Workspace-Default-Optionen. Welche Compliance dabei effektiv gilt, hängt davon ab, mit welchem JDK der Launcher gestartet wurde (`JAVA_HOME`, sonst `java` im PATH). - Ein Test gegen arknet (Java 25) am 2026-09-07 konnte importieren und Referenzen suchen; die Probleme dort lagen bei Test-Output-Ordnern und dem JUnit-Loader (#71), nicht bei `--release 25`. **Nächster Schritt:** Mit einem `--release 25`-Modul reproduzieren und die konkrete Fehlermeldung hier ablegen (`jdt_get_compilation_errors` und `jdt_get_project_structure` → `compliance`). Wahrscheinlicher Fix: Compliance beim Import aus der POM übernehmen.

hauschel.fred added the

bug

headless

P3-medium

labels

2026-09-07 16:24:51 +00:00

hauschel.fred added this to the v1.2.0 – Ergonomie & Skalierung milestone

2026-09-07 16:28:05 +00:00

Commenting is not possible because the repository is archived.