AssertionFailedException in TextFileChange.releaseDocument() bei Package-Rename mit renameSubpackages #77

New issue

Open

opened 2026-03-09 10:22:49 +00:00 by automation · 0 comments

automation commented

2026-03-09 10:22:49 +00:00

Collaborator

Beschreibung

Beim Ausführen eines Package-Renames mit renameSubpackages: true tritt eine AssertionFailedException auf. Der Preview funktioniert fehlerfrei, nur die tatsächliche Ausführung schlägt fehl.

Reproduktion

jdt_rename_element(
  elementName: "com.culinarygraph.rdf",
  newName: "de.g4ch.rdf",
  elementType: "PACKAGE",
  renameSubpackages: true,
  preview: false
)

Testprojekt: /home/naturzukunft/tmp/testPrj/rdf (Branch: refactor/package-rename-18) mit /home/naturzukunft/tmp/testPrj/platform im Workspace.

Verhalten

Szenario	Ergebnis
Preview mit `renameSubpackages: false`	OK
Preview mit `renameSubpackages: true`	OK
Ausführung mit `renameSubpackages: false`	OK (aber Referenzen nicht aktualisiert — separates Problem)
Ausführung mit `renameSubpackages: true`	FEHLER

Stacktrace

org.eclipse.core.runtime.AssertionFailedException: assertion failed: 
  at org.eclipse.core.runtime.Assert.isTrue(Assert.java:121)
  at org.eclipse.core.runtime.Assert.isTrue(Assert.java:106)
  at org.eclipse.ltk.core.refactoring.TextFileChange.releaseDocument(TextFileChange.java:252)
  at org.eclipse.jdt.core.refactoring.CompilationUnitChange.releaseDocument(CompilationUnitChange.java:92)
  at org.eclipse.ltk.core.refactoring.TextChange.perform(TextChange.java:249)
  at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:279)
  at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.access$0(DynamicValidationStateChange.java:1)
  at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.lambda$0(DynamicValidationStateChange.java:105)
  at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:41)
  at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:751)
  at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2505)
  at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2533)
  at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:6142)
  at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.perform(DynamicValidationStateChange.java:106)
  at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:279)
  at org.naturzukunft.jdt.mcp.tools.RefactoringSupport.performChange(RefactoringSupport.java:204)
  at org.naturzukunft.jdt.mcp.tools.RenameRefactoring.renameElement(RenameRefactoring.java:221)

Analyse

performChange() ruft korrekt initializeValidationData() vor perform() auf
Die Assertion in TextFileChange.releaseDocument() prüft fAcquiredDocumentCount > 0
Bei komplexen CompositeChange-Bäumen (Package-Rename über mehrere Projekte mit Subpackages) scheint die Document-Lifecycle-Verwaltung (acquire/release) nicht korrekt zu funktionieren
Möglicherweise werden bei verschachtelten DynamicValidationStateChange → CompositeChange → CompilationUnitChange die Dokumente mehrfach released

Hinweis

Der vorherige Bug (IllegalArgumentException in ProjectScope.getNode() → CodeStyleConfiguration) ist gefixt.

## Beschreibung Beim Ausführen eines Package-Renames mit `renameSubpackages: true` tritt eine `AssertionFailedException` auf. Der Preview funktioniert fehlerfrei, nur die tatsächliche Ausführung schlägt fehl. ## Reproduktion ``` jdt_rename_element( elementName: "com.culinarygraph.rdf", newName: "de.g4ch.rdf", elementType: "PACKAGE", renameSubpackages: true, preview: false ) ``` **Testprojekt:** `/home/naturzukunft/tmp/testPrj/rdf` (Branch: `refactor/package-rename-18`) mit `/home/naturzukunft/tmp/testPrj/platform` im Workspace. ## Verhalten | Szenario | Ergebnis | |----------|----------| | Preview mit `renameSubpackages: false` | OK | | Preview mit `renameSubpackages: true` | OK | | Ausführung mit `renameSubpackages: false` | OK (aber Referenzen nicht aktualisiert — separates Problem) | | Ausführung mit `renameSubpackages: true` | **FEHLER** | ## Stacktrace ``` org.eclipse.core.runtime.AssertionFailedException: assertion failed: at org.eclipse.core.runtime.Assert.isTrue(Assert.java:121) at org.eclipse.core.runtime.Assert.isTrue(Assert.java:106) at org.eclipse.ltk.core.refactoring.TextFileChange.releaseDocument(TextFileChange.java:252) at org.eclipse.jdt.core.refactoring.CompilationUnitChange.releaseDocument(CompilationUnitChange.java:92) at org.eclipse.ltk.core.refactoring.TextChange.perform(TextChange.java:249) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:279) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.access$0(DynamicValidationStateChange.java:1) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.lambda$0(DynamicValidationStateChange.java:105) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:41) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:751) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2505) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2533) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:6142) at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.perform(DynamicValidationStateChange.java:106) at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:279) at org.naturzukunft.jdt.mcp.tools.RefactoringSupport.performChange(RefactoringSupport.java:204) at org.naturzukunft.jdt.mcp.tools.RenameRefactoring.renameElement(RenameRefactoring.java:221) ``` ## Analyse - `performChange()` ruft korrekt `initializeValidationData()` vor `perform()` auf - Die Assertion in `TextFileChange.releaseDocument()` prüft `fAcquiredDocumentCount > 0` - Bei komplexen CompositeChange-Bäumen (Package-Rename über mehrere Projekte mit Subpackages) scheint die Document-Lifecycle-Verwaltung (acquire/release) nicht korrekt zu funktionieren - Möglicherweise werden bei verschachtelten `DynamicValidationStateChange` → `CompositeChange` → `CompilationUnitChange` die Dokumente mehrfach released ## Hinweis Der vorherige Bug (`IllegalArgumentException in ProjectScope.getNode() → CodeStyleConfiguration`) ist gefixt.