String-Manipulation statt ASTRewrite in CodeGenerationTools #52

New issue

Open

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

automation commented

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

Collaborator

Problem

CodeGenerationTools manipuliert Java-Sourcecode direkt als String statt ASTRewrite zu verwenden. Das verletzt AST-001 (keine direkte String-Manipulation).

Betroffene Methoden

addMethod() (Zeile ~200) — source.lastIndexOf('}') trifft falsche Stelle bei inneren Klassen
addField() (~364) — gleiche Problematik
addImplementsClause() (~658) — 75-Zeilen-Parser für Java-Syntax, fragil bei @Annotations, sealed, permits
generateMissingMethods() (~737) — Signature.toString() liefert JDT-interne Signaturstrings

Zusätzlich

addMethod/addField nutzen cu.getBuffer().setContents() ohne Working Copy (verletzt AST-004). ConvertToLambdaRefactoring und ImportOrganizer machen es richtig mit becomeWorkingCopy/commitWorkingCopy.

Lösung

ASTRewrite mit ListRewrite.insertLast() und Working-Copy-Pattern verwenden.

Gefunden von

Vogel (kritischster Befund)

## Problem `CodeGenerationTools` manipuliert Java-Sourcecode direkt als String statt ASTRewrite zu verwenden. Das verletzt AST-001 (keine direkte String-Manipulation). ### Betroffene Methoden - **`addMethod()`** (Zeile ~200) — `source.lastIndexOf('}')` trifft falsche Stelle bei inneren Klassen - **`addField()`** (~364) — gleiche Problematik - **`addImplementsClause()`** (~658) — 75-Zeilen-Parser für Java-Syntax, fragil bei `@Annotations`, `sealed`, `permits` - **`generateMissingMethods()`** (~737) — `Signature.toString()` liefert JDT-interne Signaturstrings ### Zusätzlich `addMethod`/`addField` nutzen `cu.getBuffer().setContents()` ohne Working Copy (verletzt AST-004). `ConvertToLambdaRefactoring` und `ImportOrganizer` machen es richtig mit `becomeWorkingCopy`/`commitWorkingCopy`. ### Lösung ASTRewrite mit `ListRewrite.insertLast()` und Working-Copy-Pattern verwenden. ## Gefunden von Vogel (kritischster Befund)