ElementLookup konsolidieren — findType, getJavaProject, resolveElement 4-fach dupliziert #53

New issue

Open

opened 2026-03-08 18:38:39 +00:00 by automation · 0 comments

automation commented

2026-03-08 18:38:39 +00:00

Collaborator

Problem

Die Element-Lookup-Logik (Typ-, Methoden- und Feld-Auflösung) existiert in 4+ Varianten mit subtilen Unterschieden:

findType / findTypeByName (identisch, 4 Kopien)

Klasse	Methode	Besonderheit
`CodeAnalysisTools`	`findType()` (Zeile 466)	Kein `isBinary()`-Check, kein `isOpen()`-Check
`NavigationTools`	`findTypeByName()` (Zeile 411)	Kein `isBinary()`-Check, kein `isOpen()`-Check
`CodeGenerationTools`	`findTypeByName()`	Kein `isBinary()`-Check
`RefactoringSupport`	`findTypeInSourceProject()` (Zeile 37)	Korrekt: prüft `isBinary()`, `getResource()`, `isOpen()`

Nur RefactoringSupport hat die korrekte Implementierung. Die anderen können Binary-Typen zurückgeben, was bei getSource() zu JavaModelException führt.

getJavaProject (identisch, 2 Kopien)

ProjectInfoTools.getJavaProject() (Zeile 719)
CreationTools.getJavaProject() (Zeile 359)

resolveElement / findMember (4 Varianten)

Die className#memberName Parsing- und Auflösungslogik:

CodeAnalysisTools.resolveElement() (Zeile 416)
CodeAnalysisTools.getSourceRange() (Zeile 334, inline)
RefactoringSupport.findElement() (Zeile 58)
DocumentationTools.findMember() (Zeile 481)

Vorschlag

Neue Klasse ElementLookup (oder JavaModelHelper) die alle Varianten konsolidiert:

findTypeInSourceProject(String fqn) — die korrekte Implementierung aus RefactoringSupport
getJavaProject(String name) — zentral
resolveElement(String elementName) — className#memberName Parsing + Auflösung

Gefunden von

Alle 5 Reviewer übereinstimmend — der meistgenannte Befund

## Problem Die Element-Lookup-Logik (Typ-, Methoden- und Feld-Auflösung) existiert in 4+ Varianten mit subtilen Unterschieden: ### findType / findTypeByName (identisch, 4 Kopien) | Klasse | Methode | Besonderheit | |--------|---------|-------------| | `CodeAnalysisTools` | `findType()` (Zeile 466) | Kein `isBinary()`-Check, kein `isOpen()`-Check | | `NavigationTools` | `findTypeByName()` (Zeile 411) | Kein `isBinary()`-Check, kein `isOpen()`-Check | | `CodeGenerationTools` | `findTypeByName()` | Kein `isBinary()`-Check | | `RefactoringSupport` | `findTypeInSourceProject()` (Zeile 37) | **Korrekt**: prüft `isBinary()`, `getResource()`, `isOpen()` | Nur `RefactoringSupport` hat die korrekte Implementierung. Die anderen können Binary-Typen zurückgeben, was bei `getSource()` zu `JavaModelException` führt. ### getJavaProject (identisch, 2 Kopien) - `ProjectInfoTools.getJavaProject()` (Zeile 719) - `CreationTools.getJavaProject()` (Zeile 359) ### resolveElement / findMember (4 Varianten) Die `className#memberName` Parsing- und Auflösungslogik: - `CodeAnalysisTools.resolveElement()` (Zeile 416) - `CodeAnalysisTools.getSourceRange()` (Zeile 334, inline) - `RefactoringSupport.findElement()` (Zeile 58) - `DocumentationTools.findMember()` (Zeile 481) ## Vorschlag Neue Klasse `ElementLookup` (oder `JavaModelHelper`) die alle Varianten konsolidiert: - `findTypeInSourceProject(String fqn)` — die korrekte Implementierung aus RefactoringSupport - `getJavaProject(String name)` — zentral - `resolveElement(String elementName)` — `className#memberName` Parsing + Auflösung ## Gefunden von Alle 5 Reviewer übereinstimmend — der meistgenannte Befund