Community
Participate
Working Groups
In the codebase I work with, names such as "Builder" are ubiquitous. We have a nested Builder class in practically half of all types. When performing refactors and using other code completion features, Eclipse chooses to import any class it needs to refer to, directly. This means that the first builder class we used is imported directly as "Builder," and any further builders are referred to as "com.some.really.long.package.name.ClassIAmBuilding.Builder" in each needed occurrence. It would be great if Eclipse could import "ClassIAmBuilding" and then refer to the builder as "ClassIAmBuilding.Builder" in the code. Most commonly, this is used as return types or parameter types. This also happens when extracting locals, or declaring an undeclared variable being assigned. I am happy to maintain a blacklist of class names, such as Builder, to never import directly. There are also some context clues available in the code to help in making this decision, such as referring to the type as "ClassIAmBuilding.Builder" elsewhere, but sometimes "elsewhere" means "in a different file" and so might be impractical. Another good metric for this is how many different classes have that name (I have so many different builder classes that eclipse sometimes locks up for a while populating "quick fix" suggestions—a small irony whose comedic value is usually lost on me when it happens). Still, I would be happy with the blacklist.
Perhaps Eclipse could learn the blacklist from user behavior. For example, if you ever manually change the import of an inner class to be an import of its containing class, that class could automatically get added to the blacklist. If the user ever manually changes an import in the other direction, it could get removed from the blacklist. This blacklist could be remembered on a per-user basis. We could populate an initial set of defaults by either examining the code base or hardcoding a list somewhere in an invisible preference. Joshua: if you'd like to take a stab at implementing this, check out my guide for setting up Eclipse for platform UI development. https://wiki.eclipse.org/Platform_UI/How_to_Contribute Working on JDT is pretty much the same, except that you should select the "JDT" projects instead of the "Platform > UI" project.
(In reply to Stefan Xenos from comment #1) Auto-updating blacklist would be a good feature, but a static blacklist explicitly controlled from a preference page would be much easier to implement. It makes sense to start from that and add auto-updating later, when and if it becomes clear that a static list doesn't satisfy a significant number of users.
True, a static blacklist is better than what we have now and auto-updating could always be added later as a separate feature.
