Bug 355568

Description Mohsen Vakilian 2011-08-23 16:06:27 EDT

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