A good way to learn Eclipse refactoring tools is to force yourself to ensure your code ALWAYS compiles. A lazy but common way to modify an API is to make your change destructively, and then resolve all the compilation errors. That way you “know you got them all”. However, if you discipline yourself to never introduce a compilation error, it will force you to learn some of the more powerful Eclipse refactoring tools. I believe this discipline results in more stable code.
It got me thinking. The way we do code merges now is so 1970s. We compare streams of meaningless bytes, with some primitive pattern-matching. (This is a bit of an exaggeration, but I suspect mostly true.)
Wouldn’t it be interesting if, instead of a change-set consisting of a list of diffs, deletes, and adds, it instead consisted of a list of refactoring operations? It’s a bit of a fanciful question to ask in 2011, but imagine how much more straightforward code merges would be!