Martin Fowler
Chief Scientist, ThoughtWorks
In January 2001 two Java tools crossed Refactoring's Rubicon. Refactoring in Java now has serious tool support
As I suspect anyone who's reading this knows, I'm a big fan of refactoring. It's something I've wrote about and talked about for several years now. But one thing I also know is that this is the early days of refactoring. In my book, I describe how to manually refactor programs. Yet manual refactoring really is about cutting down a forest with an axe - we need refactoring tools to take a real chain saw to the problem.
Of course refactoring tools are not unknown. Even before I started work on the refactoring book, John Brant and Don Roberts came up with the Smalltalk Refactoring Browser. This awesome tool makes refactoring much quicker and more pleasurable. The trouble is that it is a Smalltalk tool, and not many people are using Smalltalk. Indeed I've hardly ever used the Refactoring Browser because most of the work I've done in the last few years has been in Java.
But the Refactoring Browser makes one thing very clear. Tool support for refactoring is both possible and valuable. I always believed it was only a matter of time. As a popular memory-managed language, I expected that Java would soon have such tools.
In 1999 a number of people contacted me about tools they were working on that supported refactoring. I keep a list of these tools at http://www.refactoring.com/(there another list on the wiki). Although refactoring.com is hardly a hub of the web people clearly wanted to be listed amongst the refactoring tools.
However I'm not at all interested in reviewing refactoring tools on the site. There are many things that interest me, but reviewing software products is not one of them. I'm happy to keep a list, but reviews I'll leave to others.
Having said that some minimum standards are in order. A couple of vendors wanted me to mention their tools. I looked at their "Move Method" capability, and found that although they could move a method body from one class to another, they didn't alter the callers. As a result a program no longer compiles after applying the transformation: hardly semantics preserving!
There were tools that were more honest about their capabilities. A number offered the ability to do various kinds of renaming, such as Rename Method. Now providing the callers are adjusted, renaming counts as a refactoring - and a very useful one to boot. Also several tools support Move Class and, since repackaging is a pain in the neck in Java, this is a very useful refactoring.
All of these were encouraging signs. But even so I was not seriously excited. All these were steps, but there was a key barrier to cross.
The kinds of renames that I've been talking about require some analysis of the software, but it's fairly shallow. You can do renames with without going too deep into the structure of the program. Indeed many people do renames manually by editor search/replace or through simple regular expression based scripts. To go the full extent into refactoring you actually have to analyze and manipulate the parse tree of the program, as John and Don describe in the book.
A refactoring that needs this capability is Extract Method. While one reviewer on amazon described this as merely cut and paste, Extract Method actually requires some serious work. You have to analyze the method, find any temporary variables, then figure out what to do with them. The analysis is not something you can do by regular expression manipulation. It requires some careful work.
That's why I see it as a key refactoring. If you can do Extract Method, it probably means you can go on more refactorings. It's the sign that says "I'm serious about this".
The first thing that made me think there was a serious attempt at crossing the Rubicon was in mid-1999 when I was contacted by Instantiations. For those that don't know, Instantiations is one of the most highly regarded names in OO circles. Born out of the Portland Smalltalk community the company was one of the major parts of Digitalk and did a lot of serious work in Smalltalk. Since then they've moved onto to Java and developed several products, including Jove - a native compiler.
So when Instantiations said they were starting work on a refactoring tool (then codenamed Alchemy - now called jFactor) I was excited because I knew they had the understanding to do a good job. I was even more encouraged when they said that the first refactoring they were going to tackle was Extract Method.
However they weren't the first across the river. That prize goes to X-ref: a plug in for emacs developed by Marian Vittek. To be honest this didn't have a big effect on me as I don't do my Java in emacs. Also x-ref's extraction has some limitations and Marian's outfit is a small operation. But it got there and is well worth looking at if you use emacs regularly.
If X-ref was the rowboat crossing the Rubicon, Instantiations crossed the river in style. Their tool jFactor supports a nice list of refactorings, including Extract Method, in a very professional looking tool. jFactor is available as a plug in for IBM's Visual Age for Java. Now extract method is just a case of select the code, choose the menu item, and type in the name. Refactoring is here in style.
jFactor was enough for me to consider January 2001 a banner month for refactoring, but I got a pleasant surprise. For a while IntelliJ have been building an IDE for Java that was liked for its Visual Age like searching capabilities. They added various renaming capabilities to the tool which made it a minor favorite on the sixth floor here where we were unable to use Visual Age. Then in January I got a surprise email - their IDEA tool now supports Extract Method.
The January flurry is exiting for me, as I'm convinced that refactoring tools are going to make a big impact on software engineering. Indeed I've called John and Don's Refactoring Browser the biggest step forwards in development tools since the IDE. I also hope that now the Rubicon of Extract Method is crossed, more refactorings will follow. Certainly I urge you check out these tools and try out their refactoring capabilities.
As a side note, I'm not going to provide reviews of these tools. Doing a proper review is too time consuming. I do keep in touch with these vendors and will be doing what I can to help their developments. However I would be interested in seeing feedback on these tools and will continue to maintain a list on refactoring.com information about refactoring tools. I'll also post tool news on that site as the vendors share it with me.
© Copyright Martin Fowler, all rights reserved