Community
Participate
Working Groups
Build Identifier: 20110615-0604 We have studied the developers' use of specific features of the Eclipse IDE in the CodingSpectator <http://codingspectator.cs.illinois.edu> study. Our study has provided us with rich usage data about the use of refactoring tools in Eclipse. We have analyzed the data that CodingSpectator has collected from our participants and discovered a few problems with the usability of the Eclipse refactoring tools. We'd like to share our findings with the developers of Eclipse to discuss possible solutions to these usability problems. While analyzing the data collected by CodingSpectator, we noticed occurrences of the following error messages during the Rename refactoring. Message A: Type named 'xxx' is imported (single-type-import) in 'xxx' (a compilation unit must not import and declare a type with the same name) Message B: Another type named 'xxx' is referenced in 'xxx.java' To see how the refactoring tool may report the above messages, consider the following piece of code: //C.java package p; import q.D; public class /*START SELECTION A*/C/*END SELECTION A - Invoke Rename refactoring to rename 'C' to 'D'.*/ { public static void main(String[] args) { D d = new D(); } } //D.java package q; public class /*START SELECTION B*/D/*END SELECTION B - Invoke Rename refactoring to rename 'D' to 'C'.*/ { } If you perform the rename refactoring as described in the comments for selections A and B, the refactoring tool will report messages A and B, respectively. Two of our participants who encountered these error messages decided to proceed with the refactoring and fix the result of the refactoring tool manually. The data from CodingSpectator says that our participant has spent six seconds on the dialog that reported the message B. It looks like the pre-conditions of the Rename refactoring are too strong in these cases. The refactoring tool could have been more flexible and let the two classes in different packages have the same names. We wonder why the Rename refactoring tool of Eclipse prevents two classes with the same names in different packages. Is it technically challenging to perform the Rename refactoring and update the code to refer to the two classes with the same names correctly? Wouldn't it better match the expectations of the programmers if the Rename refactoring tool does not warn the programmer about a safe use of the same names in different packages? Reproducible: Always
(In reply to comment #0) > Build Identifier: 20110615-0604 Rename Refactoring also updates references by default (Try to rename to some other name and see what happens) It is also behavior preserving hence gives you those errors because of an existing import/reference to the other class. > We wonder why the Rename refactoring tool of Eclipse prevents two classes with > the same names in different packages. It doesn't if you don't have references to one class in the other.
(In reply to comment #1) > (In reply to comment #0) > > Build Identifier: 20110615-0604 > > Rename Refactoring also updates references by default (Try to rename to some > other name and see what happens) It is also behavior preserving hence gives you > those errors because of an existing import/reference to the other class. Raksha, this bug is about being smarter in such cases (replace import with fully qualified types). *** This bug has been marked as a duplicate of bug 33222 ***
Dani is right. We are suggesting that the rename refactoring be more flexible and assist the programmer in making the change. Based on the results of our empirical study [1], programmers prefer flexible refactoring tools than restrictive ones. For example, we observed that programmers performed automated refactorings even though the tools had reported some errors. Eclipse is almost certain that the refactoring is going to break the code when it presents an error. But, such errors don't prevent programmers from using the tools. Programmers would still prefer to perform the erroneous refactoring to get some of the task done. Often, there are ways to make the tool more flexible and not report any errors. This bug report is an example of a case where the tool could have been more flexible and not report an error. [1] http://hdl.handle.net/2142/27730
