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.

Bug 262237 - Rename method will produce incorrect code for shadowed calls
Summary: Rename method will produce incorrect code for shadowed calls
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 8.2
Hardware: PC Linux
: P3 normal (vote)
Assignee: Ralph Ruijs
Depends on:
Reported: 2016-05-26 11:38 UTC by Svata Dedic
Modified: 2016-05-27 13:54 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Svata Dedic 2016-05-26 11:38:59 UTC
Related to defect #256404. 

Consider this source:

public class Super {
    public void m() {}

public class Test extends Super {
    public void n() {}
    public void foo() {

Renaming Test.n() to m() produces the following code for foo():

    public void foo() {

it should call Super.super.m();
Comment 1 Svata Dedic 2016-05-26 12:21:43 UTC
Consider the same situation + add

public class SubTest extends Test {
    public void bar() {

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 :)
Comment 2 Svata Dedic 2016-05-27 13:19:32 UTC
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()
Comment 3 Svata Dedic 2016-05-27 13:54:13 UTC
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.