Posted by tball
on May 10, 2007 at 10:10 PM PDT
The slides to my talk "Advanced Java Refactoring: Pushing the Envelope" are available on the Jackpot project site.
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.