Tom Ball is a senior staff engineer at Sun Microsystems, working on Java language tools.
He has been working with Java for twelve years now with the JDK, AWT, Swing, Jackpot, and NetBeans teams.
Tom considers programming a craft, and is always looking for new tools and techniques to improve it.
Jackpot Project Page
Tom Ball's Blog
At its heart, Jackpot is a platform library for easily finding and correcting patterns
in Java source code using static analysis.
There are two key differences:
Most refactoring tools are fairly difficult to extend,
so a lot of effort has gone into making Jackpot easy (or easier) to do so.
In addition to a rich API for creating query and transformation classes,
Jackpot provides a pattern-matching (rule) language for Java statements and expressions.
We are also putting work into making it easy to share these extensions
with co-workers and fellow community members.
The data model that Jackpot searches and transforms has more detailed and
correct information about the source code than most, if not all,.
I don't think the Jackpot team is any more capable of creating a correct semantic model
for all Java source code than other refactoring teams (they are all excellent engineers),
but I do believe that Sun's javac team has the best chance of getting it right
(and the most feedback when they don't).
By leveraging javac, we are "standing on the shoulders of giants".
These are both great tools with different strengths.
Although I haven't done a query-by-query analysis,
my impression is that it is possible to write any of the queries
either of these tools have using either Jackpot's rule language or its API —
there is nothing missing from Jackpot's model that would preclude any of these analyses.
FindBugs and PMD also have the advantage of being able to run from the command-line and by the Ant build tool.
My limited understanding is that the "Inspect Code" command in IntelliJ IDEA
is another "anti-pattern" detector like FindBugs and PMD.
Like Jackpot, it has the ability to fix many of these problems,
but its UI requires that you select each problem separately and click on the command to fix it.
It also doesn't show you a diff window with the old and new source like Jackpot can,
so you just have to trust that it will be correct before invoking the command.
Finally, it takes IDEA significantly longer to read in a large project;
I don't mean that as a criticism of their parser, but rather it demonstrates how fast javac is.
You've been working with sample code too long — these days 20,000 lines is pretty small
for many Java projects!
At James Gosling's keynote at JavaOne 2006, I demonstrated Jackpot with a medium-sized project
that had a quarter of a million lines of code, and it took less than half a minute on my old laptop
to read the project and execute several queries.
It's true that big projects take more memory and time,
but for NetBeans 6.0 we have some ideas on ways to minimize some of the overhead.
On the other hand, if you are working on a big project it's easy to justify
a max'ed out Sun Ultra 40, as it has more than enough memory for the biggest projects
and should pay for itself quickly from the productivity boost.
(No, I'm not in sales, but am rehearsing these justifications so my boss will buy me one soon.)
No, it requires the project support (where are the source files, libraries, how is it built, etc.)
and user interface support NetBeans IDE provides.
We certainly could have implemented Jackpot as a separate tool,
but it would have taken a lot longer recreating all of the infrastructure the NetBeans IDE provides.
If you are just using Jackpot, either with its built-in queries
or with queries a team member wrote, you shouldn't care —
And if you are using Jackpot's rule language such knowledge is optional (but useful).
But if you want to write a custom query, here are the gory details.
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}
source-file: HelloWorld.java
+ class
+ name
+ identifier: HelloWorld
+ modifiers: public
+ method
+ name: main
+ modifiers: public, static
+ arguments
+ parameter
+ type: String[]
+ name: args
+ return-type: void
+ block
+ method-invocation: System.out.println
+ arguments
+ string-literal: "Hello, world!"
By "you" I hope you meant past and present members of the Jackpot team,
because the language was designed by James Gosling.
He didn't create the language to solve all refactoring problems,
but instead wanted a simple way to express the sorts of changes we were making for API migration.
API migration involves moving source code from one API to another,
such as rewriting deprecated method use to non-deprecated replacement methods.
Using the Java core classes as an example,
it's easy to find hundreds of methods to be mapped using very similar patterns,
and writing a visitor to handle all of them would be a maintenance nightmare.
He therefore created a "little language" to handle those sorts of transformations,
with the key guideline being simplicity.
It cannot handle all queries, but the transformations it can handle can be expressed
in a short fragment of very legible code.
$object.show() => $object.setVisible(true) ::
$object instanceof java.awt.Component;
Component.show()
Component.setVisible(true)
Component
instanceof
show()
For NetBeans 6.0 Jackpot will become a part of the core IDE,
and its engine will merge into a new Java source model facility which will be shared by the rest of the IDE.
Its user interface and developer support features will mostly remain,
but will be better integrated with the existing refactoring support.
One feature I'm looking forward to is the ability for anyone to create Jackpot queries
and add them as Java editor tips (the little light bulbs that show when a code improvement is suggested).