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: | Rename method will produce incorrect code for shadowed calls | ||
|---|---|---|---|
| Product: | java | Reporter: | Svata Dedic <sdedic> |
| Component: | Refactoring | Assignee: | Ralph Ruijs <ralphbenjamin> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 8.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
Consider the same situation + add
public class SubTest extends Test {
public void bar() {
m();
}
}
if Test.n() is renamed to m(), SubTest.m() will start calling Test.m() instead of Super.m() ... There should be at least warning for the user that she may screw up subclasses :)
As I am fixing similar feature in Introduce hints, I've noticed that refactoring changes existing method calls although they could be left alone:
In the above example, add
public void x(int a) {}
to class Test and then refactor-rename it to m.
The refactoring transformer will change m() call into Super.this.m() although the newly introduced symbol m(int) does not hide super.m()
And yet another ... rename warns when the introduced symbol's signature is the same as existing method, but it should check erasures as well.
suppose there are methods
public void a(List<String> par) {}
public void b(List<Object> par) {}
refactoring/rename will happily rename b to a, producing an erroneous source.
|
Related to defect #256404. Consider this source: public class Super { public void m() {} } public class Test extends Super { public void n() {} public void foo() { m(); } } Renaming Test.n() to m() produces the following code for foo(): public void foo() { Super.this.m(); } it should call Super.super.m();