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.
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 '
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”