This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Broken rewrite of ClassTree | ||
|---|---|---|---|
| Product: | java | Reporter: | Jan Pokorsky <jpokorsky> |
| Component: | Source | Assignee: | Pavel Flaska <pflaska> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | ||
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 76502 | ||
| Attachments: | NPE | ||
Works correctly in current trunk build. Still broken. Now it ignores super(...) statement.
public class NewClass extends B {
NewClass(int a) {
// <-- here should be method super(a);
}
void m() {
}
}
Created attachment 52126 [details]
NPE
When I tried to reproduce the current behavior, I got the exception above. Although, I expect once the exception will be fixed, the issue will come back to java/source. Perhaps I will remove guess if the super is synthetic or not and will move responsibility to API clients. Once NPE will be fixed, please, reassign it back. The NPE seems to be fixed. Reassigning back. Checking in src/org/netbeans/modules/java/source/pretty/VeryPretty.java; /cvs/java/source/src/org/netbeans/modules/java/source/pretty/VeryPretty.java,v <-- VeryPretty.java new revision: 1.71; previous revision: 1.70 done |
Having class A class A extends B { A(int a) { super(a); } void m() { } } and class B class B { B(int a) { } } if I run Extract Superclass refactoring, with method m() selected for extraction, the new extracted class contains wrong members. public class NewClass extends B { NewClass(int a) { super(a); } NewClass() { // <-- here should be method m() } } In debugger, the new ClassTree passed to WorkingCopy.rewrite looks OK. You can find code creating NewClass in org.netbeans.modules.refactoring.java.plugins.ExtractSuperclassRefactoringPlugin.CreateSuperclassElement.run