Jackpot is not the Holy Grail (but pretty darn close)

Jackpot
is probably the most exciting technology I’ve seen while at Sun and it
is now coming to an Open Source IDE near you: NetBeans.

I first heard about it straight from James Gosling 4-5 years ago at an
internal conference. Then, around 2003, there was also this “Why Moving
Methods is Hard” (internal?) paper by James which discusses real-world (jdk)
debugging of Jackpot actions. Both very instructive.

While being capable of doing refactoring (only maybe with safer results
by working at the semantic level), I see Jackpot as being also able
to macro-refactor at a higher level of abstraction. Imagine
safely moving from one logging API to another in your entire code.

The original goal
of Jackpot was to make sense of big chunks of Java code to be ready to
deal with dead (as in Cobol) Java legacy. Parts of Jackpot already made its
way into Creator to keep in sync the visual code views (visual designer,
navigation rules, …), but also in NetBeans’ Metrics and Classfile modules.

Tom Ball
now has the leadership on this project. Compared to the early days, it
now has tight integration with javac. If you’ve decided to use
javac (with or without an IDE), it’s was probably a good idea given the
recent improvements to the compiler to expose the Java model.
You should be able to benefit quite easily from Jackpot <!–(maybe even
using the '-Xlint:‘ framework)–>.

Recent jackpot coverage started at last Javaone (see TS-7143),
followed later by a little
example
last summer by Roumen, then the Sun
Tools FAQ
mentioned it, and now  there’s Tom
Ball’s recent blog
.

Going though Tom’s
JavaOne talk
one more time, I gathered these quotes :
“Jackpot is
Refactoring on Steroids”

– (on Jackpot working at the semantic level) “If you can fool Jackpot, you
can fool javac”

– (on Jackpot scaling to large code bases) “linear progression between the
number of rules and how long it takes to apply them all”

Advertisements

Author: alexismp

Google Developer Relations in Paris.

2 thoughts on “Jackpot is not the Holy Grail (but pretty darn close)”

  1. Ok, fair enough, I probably should have started there.

    Jackpot is a technology for manipulating (querying, transforming) big chunks of code in a safe manner). It does so by leveraging the compiler’s (javac) ability to model source files.

    It can be used for classic but also high-level refactorings such as moving business logic from one technology to another (from servlet to EJB, from one version of EJB to EJB 3, from a logging framework to another one), and IDEs such as NetBeans can certainly leverage this.

    I would suggest listening to the JavaOne Jackpot talk here.

Comments are closed.