Bug 351506

Summary: [rename] Eclipse fails to rename a method in a Java project that transitively depends on the project that declares this method
Product: [Eclipse Project] JDT Reporter: Stas Negara <snegara2>
Component: UIAssignee: Markus Keller <markus.kell.r>
Status: NEW --- QA Contact:
Severity: minor    
Priority: P3 CC: daniel_megert, deepakazad, markus.kell.r, nchen, reprogrammer, satyam.kandula, snegara2
Version: 3.7   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard: stalebug
Attachments:
Description Flags
Three Java projects that reveal the described problem.
none
Plugin projects to reproduce the problem none

Description Stas Negara CLA 2011-07-07 23:12:27 EDT 
Build Identifier: 20110615-0604

While working on the CodingSpectator <http://codingspectator.cs.illinois.edu/>
project, we tried to rename a method that was referenced in a transitively dependent plugin. We expected that the name of the renamed method would be updated for all references, but Eclipse did not update it in this plugin.


Reproducible: Always

Steps to Reproduce:
1. Create three plugins: pluginA, pluginB, pluginC, and make pluginB depend on pluginA and pluginC depend on pluginB. 

2. Create class A in pluginA:

       public class A {
           public void m() {   }
       }
    
   Create class B in pluginB:

       public class B extends A {
           @Override
           public void m() {   }
       }

   Create class C in pluginC:

       public class C {
           public void someMethod() {
               new B().m();
           }
       }

3. Invoke the rename method refactoring on method m in class A and specify any new name for it (e.g. m1).

4. Eclipse will correctly change the method's name from m to m1 in classes A and B, but will not change it in class C, thus leading to a compilation error. 

Thus, Eclipse looks only for immediate dependencies while performing the rename method refactoring (possibly other kinds of refactorings as well). If pluginC had a direct dependency on pluginA, then rename refactoring would correctly update class C as well.
Comment 1 Stas Negara CLA 2011-07-08 10:01:46 EDT 
Created attachment 199332 [details]
Three Java projects that reveal the described problem.

Please note that the above scenario works correctly for plugins, i.e. method m will be correctly renamed in all plugins, including the transitively dependent pluginC. To reproduce the problem, please create Java projects (not plugins): projectA, projectB, projectC. The rest of the steps is the same. You can import these projects from the attached archive and try to rename method m in class A to reproduce this problem.
Comment 2 Deepak Azad CLA 2011-11-23 08:37:50 EST 
Created attachment 207413 [details]
Plugin projects to reproduce the problem

(In reply to comment #1)
> Please note that the above scenario works correctly for plugins, i.e. method m
> will be correctly renamed in all plugins, including the transitively dependent
> pluginC. 

Not true. The problem also happens with the attached plugin projects.
Comment 3 Deepak Azad CLA 2011-11-23 08:50:13 EST 
- Searching for 'All Occurrences' of 'A.m()' via Search dialog in both cases - Java projects and Plugin projects - does not finds the match in C.
- Removing the overridden method 'm()' from B results in a compile error in both cases.

The refactoring works perfectly when all three classes - A,B,C - are in one project.

Satyam, is this a bug in JDT/Core search?
Markus, is this a bug in the refactoring?
Comment 4 Dani Megert CLA 2012-02-21 06:59:48 EST 
It depends on how you setup the project and the plug-ins (manifest). If you let C see A in some way (either by requiring A or by letting B export A), then the rename works. However, it should also work without that.

Looks like a bug in our refactoring code. Note that if we first replace A.m() with A.f() and then rename B.m(), it correctly updates C.someMethod().

Markus, please take a look.
Comment 5 Dani Megert CLA 2012-02-21 07:00:00 EST 
.
Comment 6 Eclipse Genie CLA 2020-05-21 09:56:47 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 7 Eclipse Genie CLA 2022-05-12 16:14:53 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 8 Eclipse Genie CLA 2024-05-04 15:28:45 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.