Community
Participate
Working Groups
Build Identifier: 20090619-0625 I'm modifying an AST created by using ASTParser to parse an ICompilationUnit. The class parsed (let's call it C) has an annotation (A) which accepts a .class-literal (X.class) as parameter. The whole thing looks like this before the modification: @A(X.class) public class C {/*[...]*/} The modification comprises changing C from class to interface by calling setInterface(true) on the corresponding TypeDeclaration. I then use CompilationUnit's rewrite method to create a TextFileChange which I want to use to apply the modification. The result should look like this: @A(X.class) public interface C {/*[...]*/} But what happens instead is: @A(X.interface) public class C {/*[...]*/} See steps to reproduce for a detailed example. Reproducible: Always Steps to Reproduce: 1. Use org.junit.tests.experimental.ExperimentalTests.java from JUnit 4.7 sources as ICompilationUnit "input" to reproduce the problem. The relevant part of its source is: package org.junit.tests.experimental; import org.junit.runner.RunWith; import org.junit.runners.Suite.SuiteClasses; /*[...]*/ @RunWith(Suite.class) @SuiteClasses( { /*[...]*/}) public class ExperimentalTests { } 2. Parse the code: ASTParser parser = ASTParser.newParser(AST.JLS3); parser.setKind(ASTParser.K_COMPILATION_UNIT); parser.setResolveBindings(true); parser.setSource(input); parser.setProject(input.getJavaProject()); CompilationUnit parsed = (CompilationUnit)parser.createAST(new NullProgressMonitor()); 3. Activate recording of modifications: parsed.recordModifications(); 4. Modify the source using an ASTVisitor: parsed.accept(new ASTVisitor() { @Override public boolean visit(TypeDeclaration node) { node.setInterface(true); } }); 5. Create TextFileChange (I'm using TextFileChange because the modifications are to be part of a refactoring): TextFileChange change = new TextFileChange(input.getElementName(), (IFile)input.getResource()); change.setTextType("java"); Document document = new Document(input.getSource()); TextEdit edit = parsed.rewrite(document, input.getJavaProject().getOptions(true)); change.setEdit(edit); 6. Apply the TextFileChange: change.perform(new NullProgressMonitor());
This is bad. I am investigating.
Created attachment 164574 [details] Proposed fix + regression tests
Released for 3.6M7. Added tests in: org.eclipse.jdt.core.tests.rewrite.describing.ASTRewritingTypeDeclTest#testTypeDeclarationChange org.eclipse.jdt.core.tests.rewrite.describing.ASTRewritingTypeDeclTest#testTypeDeclarationChange2 org.eclipse.jdt.core.tests.rewrite.modifying.ASTRewritingModifyingOtherTest#test0005 org.eclipse.jdt.core.tests.rewrite.modifying.ASTRewritingModifyingOtherTest#test0006
(In reply to comment #0) > 2. Parse the code: > ASTParser parser = ASTParser.newParser(AST.JLS3); > parser.setKind(ASTParser.K_COMPILATION_UNIT); > parser.setResolveBindings(true); > parser.setSource(input); > parser.setProject(input.getJavaProject()); > CompilationUnit parsed = (CompilationUnit)parser.createAST(new > NullProgressMonitor()); Note that org.eclipse.jdt.core.dom.ASTParser.setSource(ICompilationUnit) also sets the project. So setProject(..) call is not necessary. Let me know if you find any issue with the next I-build.
(In reply to comment #4) > Let me know if you find any issue with the next I-build. Wow, that was fast. Thank you very much. I'll try out the latest build asap.
(In reply to comment #5) > Wow, that was fast. Thank you very much. I'll try out the latest build asap. When the bug is well explained and the steps to reproduce are clear, it helps to get it fixed.
Verified for 3.6M7 by code inspection and unit tests.