fix: use direct Processor API for rename, ensure checkFinalConditions runs (#26) #38
No reviewers
Labels
No labels
bug
build
enhancement
headless
P1-critical
P2-high
P3-medium
P4-low
refactoring
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ai-tools/jdt-mcp-server!38
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/26-rename-processor-api"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Fixes #26 —
jdt_rename_elementreports SUCCESS but changes nothing (silent no-op).Root cause: The fix chain #20→#22→#24 treated symptoms but skipped
checkFinalConditions(), which is where the RenameProcessor searches references and computes TextEdits. Without it,createChange()produces an empty CompositeChange (childCount:0).Changes
RenameFieldProcessor,RenameTypeProcessor,RenameVirtualMethodProcessor/RenameNonVirtualMethodProcessor(same pattern already used forChangeSignatureProcessor)checkInitialConditions+checkFinalConditions— ifcheckFinalConditionsthrows IAE (headless preferences), initialize preferences and retry with fresh refactoring instead of skipping it entirelyMethodChecks.isVirtual()to pick correct processor (#29)ensureParticipantsInitializedreflection hack (#31),getRefactoringId,hasParticipantErrors,createAndCheckRefactoringAnalysis
Three specialized JDT expert agents (Gamma/Vogel/Duft) independently confirmed the same root cause. See #26 comments for test plan.
Test plan
mvn clean packagepassestests/smoke-test.shpasses🤖 Generated with Claude Code