Monday, March 13, 2006

Refactoring Reloaded!

WARNING: This blog entry was imported from my old blog on (which used different blogging software), so formatting and links may not be correct.

Jackpot is finally available.... well, as an alpha that is. But hey, I love to live on the bleeding edge - I always run with the latest and greatest bits I can get my hands on.

Here's the announcement, sent only to the NetBeans development mailing list. At this stage, the UI is not ready, but developers can start playing with the concepts and start writing refactoring scripts. Refactoring scripts, what's that you say?

Jackpot really is a new approach to refactoring. Sure, there are builtin refactorings - code transformations that are coded as direct AST manipulation. However, Jackpot also lets you write your own Rule files, using a special but obvious
rule language. Rather than describe it here, just
go check out the tutorial.

Unfortunately, there are no screenshots in the tutorial. And for any new software, the first thing I look for are screenshots. So, below follows a few screenshots to hopefully whet your appetite. It's exciting to see so many new innovations going into the NetBeans IDE!

Here's the first thing I did. I applied the "Add Override Annotations" transform. This goes and looks for all methods that are currently overriding another, and adds the new JDK 5 @Override annotation to all these methods. I've recently started using this annotation in my code, but I've added them haphazardly, so it's nice to be able to do this in one shot. When you run the transformer, you get a results window with diffs before you apply the change:

As I mentioned, you can write your own rule files too. This is the real big deal about Jackpot. It allows you to write your own, simple source substitutions - with full accuracy on types. The below shows some code cleanup rules. There are many many other rule files too, and more deprecated uses ones should be written.

Here's the current queries menu - queries simply list results, but doesn't actually change the code:

Here's the current transforms menu:

Note that it's very easy to add to these menus. Create your own rule files, open up the Command Manager and add a reference to your rule file (what, did you think "Tor's Test Rules" at the end of the menu above was part of the Jackpot distribution?). It then shows up in the menu and you can run it. Developers can then share these rule files. If you come up with some good rules, PLEASE please share them!

P.S. Remember it's an alpha so don't start complaining if you get exceptions, if the UI isn't Right(tm), etc.


  1. Thanks for posting the screenshots!
    Perhaps I don't understand the rules language well enough, but the rule
    { $p$; $v = $e; return $v; } => { $p$; return $e; }
    does not seem sound to me. What if $v is declared in an outer scope?

  2. I thought the same thing when I read it :) Those are only examples though and that's also why you see a diff before you end the session and validate the changes.

  3. Interesting. I'll have to read the Rule language more closely to see if there's a way to express that $v should be local to this block. There are lots of interesting Guard Expressions - see the Rules document. (Note by the way that I didn't write these expressions - these are the builtin Cleanup rules, although I swear I saw a much longer one in an earlier demo.)
    It's definitely true that one can write rules that are not "safe" though. That's sometimes a feature. For example, you can use this to apply a particular source transform to a new API which is not exactly equivalent (e.g. not a "safe" transform) but easier to do than by hand. But with the Guard expressions you should be able to qualify it such that you can trust the results.

  4. How does Jackpot compare to Eclipse's refactoring scripts?
    BTW Tor, your checkered background makes your blog hard to read.

  5. I don't know anything about Eclipse's refactoring scripts. Do you have a reference to it?
    The checkered background should be removed from blog entries (since I deliberately wipe it out using CSS) but I notice it does appear below comment text.... sorry about that. I'll mess with the template again when I get some more time.

  6. Notice teh $t before the $v in the example. The variable is only local if it has a type defined before it.

  7. So where is your rule code ?
    I don't get this rule engine language, if $a is a meta-variable is $t a meta-type? What is the difference?... this language needs some improvements.

  8. The rules language is described here:

    Navneet: There are two rules; we were referring to the one without $t. And I think that one could be rewritten as:

    { $p$; $t $v; $q$; $v = $e; return $v; } => { $p$; $q$; return $e; } :: !assignedIn($v, $q$)

    { $p$; $t $v; $q$; $v = $e; return $v; } => { $p$; $t $v; $q$; return $e; } :: assignedIn($v, $q$)

    or, possibly, just the second rule, if we know that the rule for minimizing the scope of local variables runs first.

  9. Looks awesome, Tor! A DSL is a great way to specify these transformations. Well done.