findElement gibt erstes gefundenes Element zurück — Multi-Modul-Problem #33

New issue

Closed

opened 2026-03-08 09:26:15 +00:00 by automation · 2 comments

automation commented

2026-03-08 09:26:15 +00:00

Collaborator

Problem

findElement() iteriert über alle Projekte und gibt das erste gefundene Element zurück. Bei 29 Modulen gibt es keine Garantie, dass das zurückgegebene Element aus dem Projekt kommt, das die besten Classpath-Dependencies für die Referenz-Suche hat.

Betroffener Code

RefactoringTools.java Zeilen 1731-1786

Auswirkung

Rename-Scope könnte eingeschränkt sein wenn das "falsche" Projekt gewählt wird
Bei Interface-Konstanten die in einem Modul deklariert und in vielen anderen referenziert werden, ist das Projekt der Deklaration relevant

Vorgeschlagener Fix

Bevorzuge das Projekt, das die meisten abhängigen Projekte hat, oder nutze den Workspace-weiten Scope für die Referenz-Suche.

Kontext

Identifiziert bei der Analyse von #26 durch Agent jdt-gamma (Erich Gamma).

## Problem `findElement()` iteriert über alle Projekte und gibt das **erste** gefundene Element zurück. Bei 29 Modulen gibt es keine Garantie, dass das zurückgegebene Element aus dem Projekt kommt, das die besten Classpath-Dependencies für die Referenz-Suche hat. ## Betroffener Code `RefactoringTools.java` Zeilen 1731-1786 ## Auswirkung - Rename-Scope könnte eingeschränkt sein wenn das "falsche" Projekt gewählt wird - Bei Interface-Konstanten die in einem Modul deklariert und in vielen anderen referenziert werden, ist das Projekt der Deklaration relevant ## Vorgeschlagener Fix Bevorzuge das Projekt, das die meisten abhängigen Projekte hat, oder nutze den Workspace-weiten Scope für die Referenz-Suche. ## Kontext Identifiziert bei der Analyse von #26 durch Agent jdt-gamma (Erich Gamma).

automation added the

bug

P3-medium

labels

2026-03-08 09:26:15 +00:00

fred referenced this issue from a commit

2026-03-08 16:02:22 +00:00

fix: prefer source project over binary classpath match in findElement (#33)

automation commented

2026-03-08 16:11:05 +00:00

Author

Collaborator

Fix implementiert in fix/43-refactoring-errors (Commit 3a988fb)

Neue Methode findTypeInSourceProject() bevorzugt non-binary IType mit getResource() != null — stellt sicher, dass Refactorings auf dem Quell-Projekt operieren, nicht auf einem zufälligen Classpath-Match.

Ersetzt "first project wins" Iteration an 5 Stellen:

findElement()
moveType()
extractInterface()
changeMethodSignature()
encapsulateField()

Wartet auf Test-Validierung.

**Fix implementiert** in `fix/43-refactoring-errors` (Commit 3a988fb) Neue Methode `findTypeInSourceProject()` bevorzugt non-binary `IType` mit `getResource() != null` — stellt sicher, dass Refactorings auf dem Quell-Projekt operieren, nicht auf einem zufälligen Classpath-Match. Ersetzt "first project wins" Iteration an **5 Stellen**: - `findElement()` - `moveType()` - `extractInterface()` - `changeMethodSignature()` - `encapsulateField()` Wartet auf Test-Validierung.

automation commented

2026-03-08 17:53:00 +00:00

Author

Collaborator

findTypeInSourceProject() bevorzugt jetzt non-binary IType mit getResource() != null statt "first project wins". Wird an allen relevanten Stellen verwendet (findElement, moveType, extractInterface, changeMethodSignature, encapsulateField). Fix in Branch fix/43-refactoring-errors, Commit 3a988fb.

`findTypeInSourceProject()` bevorzugt jetzt non-binary IType mit `getResource() != null` statt "first project wins". Wird an allen relevanten Stellen verwendet (findElement, moveType, extractInterface, changeMethodSignature, encapsulateField). Fix in Branch `fix/43-refactoring-errors`, Commit 3a988fb.

automation closed this issue

2026-03-08 17:53:01 +00:00

automation referenced this issue

2026-03-08 18:24:02 +00:00

fix: cross-module refactorings, error handling, JDT API migration #47