Tom Ball's Blog

"Advanced Java Refactoring" JavaOne Slides Available

Today I gave a talk at JavaOne titled "Advanced Java Refactoring: Pushing the Envelope" to a packed room, and just pushed a PDF of the slides to the Jackpot project site. Unfortunately I mismanaged the talk's time, spending too long on the demo and had to blast through the last (and, IMHO, the most interesting) slides. My apologies to those in the audience for not doing a better job by them.

It was great to see the continued interest in Java refactoring as its state-of-the-art is improving so rapidly among all the Java IDEs. I've come to rely on the 6.0 NetBeans Java editor over the past several months, in large part because many common refactorings and some new ones are fully integrated into the editor, instead of hiding in a separate Refactoring menu. Traditional refactoring improved my productivity when I first started using it many years ago, but this tighter integration is like strapping booster rockets to my chair. So my talk wasn't about the cool refactorings I'm starting to work on, but instead about how Java tools are changing the very meaning of refactoring and taking it much farther than it was first envisioned.

When debating language strengths, one thing Java engineers may be overlooking is how much Java's being a strongly-typed and statically inspectable language determines how refactorable it is. For example, the bytecode verifier that has been a part of the JVM since 1.0 puts several limits on what is considered valid code, since the verifier has to model that code accurately in order to verify it. Therefore to a certain extent, any language that can run on the JVM can be modeled fairly well. But Java adds a lot of semantic information which makes much richer models possible than with most other languages, so that language-aware tools like refactoring editors have much more information to work with when working with Java. It also avoids features that undermine modeling, such as C preprocessor abuse.

Lately I have been disappointing Sun's C and JavaScript tools engineers who want to leverage the NetBeans IDE's new Java refactoring engine (much of which is based on Jackpot), because the only answer is "no can do" -- their languages can't be statically modeled as completely as Java can. So if you get into a late-night pub discussion about how Java is so last century and that dynamic languages will soon rule the world, pick some of your favorite refactorings (those that really improve your productivity) and ask if their language/IDE supports them. Now, there are some brilliant people working on world-class languages, but they will have trouble competing with engineers leveraging the rich Java models generated by javac, Jikes, IntelliJ IDEA, and other Java tools. I suspect improved refactoring is one way Java will remain viable for many years to come.

Comments

• Tom,

  I totally agree. Many of my dynamic language using friends try to razz me about using (and preferring to use) Java. I tell them all the time that I am far more productive in Java with my IDE (refactoring et al), than they are with their language of choice. At the end of the day, none of them will really dispute this. And none of them will take me up on a "programming productivity" challenge.

  It's great to hear about how well jackpot is coming along. I can hardly wait for NB6 + Jackpot.

  -Bryan

  Posted by: prime21 on May 11, 2007 at 09:19 AM

This work is licensed under a Creative Commons License.