 |
Project Jackpot at JavaOne
Posted by tball on June 15, 2005 at 11:35 AM | Comments (11)
My apologies for not writing recently, but it has been for a good reason: I will be giving a JavaOne presentation on Project Jackpot: A New Java™ Technology for Source Transformation, and have been working hard on a NetBeans plug-in to demonstrate it. I am really excited to be able to finally discuss our work to such a wide audience.
What a long, strange trip it's been! James Gosling and Michael Van De Vanter started the Jackpot Project at Sun Labs back in the spring of 2000, and I joined a month later. For the first three years, "Jackpot" was just the project name while we investigated different ways tool improvements can enhance Java developer productivity. Rather than publish papers with our ideas, we made the radical decision (for Sun Labs, anyway) to publish our results as open-source NetBeans modules. The metrics (now obsolete) and classfile modules are a couple of Jackpot "publications".
In late 2002 we focused on an experiment James developed which read Java source into a model, applied transformations to that model, and then wrote the model back to source files. What was different about his approach is that its model allows a tool to make much more radical (but safe) changes to Java source code than is possible when working with syntax trees. The need for a deep understanding of the Java type system in a source transformation tool became even more apparent when generic types were added in Java 5. Project Jackpot therefore uses every scrap of information it can pull from javac rather than try and create its own parser, as it is a huge effort to correctly model all of the subtleties of the Java language.
When James became Sun's Chief Technical Officer of the Developer Products Group, the rest of Project Jackpot transferred over as well to the NetBeans core engineering team. Jackpot was put on hold so that javac's parser and error-checker could be leveraged by the NetBeans refactoring engine and editor. Once 4.0 released, the Jackpot engine has been re-designed and re-written (hey, it was just a research prototype!). Now that this rewrite is fairly stable, my top priority is incorporating Jackpot into NetBeans so Java developers can start using it. And yes, the plan is to make it an open-source project, just like the rest of NetBeans. As my father used to tell me, there is no rest for the wicked. :-)
I hope you are coming to JavaOne and can attend my session on Tuesday, June 28th at 1:30. I will also be attending NetBeans Software Day on Sunday the 26th. After JavaOne I will be writing more often about Project Jackpot and the tips and tricks I learned while developing it.
Bookmark blog post: del.icio.us Digg DZone Furl Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Explain it to me like i'm a 4 year old: what does it do? and why should i care?
Posted by: danielmd on June 15, 2005 at 02:15 PM
-
Jackpot is a technology that transforms Java source code: it reads in a project's source code, applies transformations to it, and writes out the files with the changes. What makes it different from, say, a batch text editor is that Jackpot understands the structure of your project's code so those edits don't break it.
As a simple example, the AWT deprecated the show() method from many of its classes, such as Component.show(). Jackpot can update those method calls to "setVisible(true)" for all Component instances (including Button, Dialog, etc.), but ignore any other classes which happen to have a show() method. Another example is that it can remove all unnecessary casts in source code, since it know what the type of the object that is being cast. It all depends on what transformations you use with it.
Posted by: tball on June 16, 2005 at 04:48 PM
-
Removing unnecessary casts and other sorts of refactoring are available in IntelliJ IDEA. But, automatically replacing deprecated methods with correct code is interesting.
Posted by: rkonjeti on June 17, 2005 at 10:13 PM
-
This would explain some of your previous comments about apt not modelling contructor/initializer/method bodies.
Is the transformation written in java, or does it use some DSL, or a general transformation language like XSLT?
Posted by: brucechapman on June 19, 2005 at 08:42 PM
-
Jackpot has a rule language which makes basic conversions relatively easy, such as API conversion, while more complicated conversions are done with visitors written in Java.
I don´t mean to sound mysterious, but since I am writing this while on vacation it will have to do. I will be able to provide more information after JavaOne -- be sure and attend my talk if you are attending!
Posted by: tball on June 21, 2005 at 09:07 AM
-
Tom,
Do you have any idea if the Jackpot modules will be added to (or work with) Java Studio Creator?
Thanks,
-- John
Posted by: johnreynolds on June 27, 2005 at 06:30 AM
-
Jackpot will be initially available as a separate module, so it should be possible to install it in other IDEs derived from NetBeans. I guess the best strategy is to try Jackpot in Creator when it becomes available, and let our community know whether you succeeded and report any problems. If Creator users find Jackpot of value, then the Creator team may choose to include it, but I haven't a clue if or when they might choose to do so.
Posted by: tball on June 28, 2005 at 12:50 PM
-
I wonder how transformations are actually declared? How easy will be to implement come custom transformations? I also wonder how Jackpot is using javac, is it just for AST model of Java source?
Posted by: euxx on July 03, 2005 at 06:47 PM
-
In brief:
Transformations are declared using a Java-like syntax that supports meta-variables and meta-types (wildcards, basically) combined with support for conditional tests (say, to only match if one of the meta-variables is a certain type).
Rule definitions are pretty straightforward, but rather than try to define a huge transformation language that can handle all possibilities, we instead focused on a simpler solution that can express maybe 80% of the transformations we've considered so far. Anything more complicated requires writing a transformation class, which is harder but much more powerful.
We use javac for its AST, and its type, name, and symbol tables. We also use it for compiling transformation rule files on-the-fly, because we found this approach much faster than using an interpreter. It is also used for transformation verification, where we reattribute the AST to catch any introduced errors. Our prototype even used it for compiling a UI script at startup -- javac is really that fast!
Lots more detail will be available when we open-source Jackpot (hopefully in the next couple of months on NetBeans.org).
Posted by: tball on July 12, 2005 at 04:34 PM
-
Hi,
Jackpot sounds like what I am looking for for the next version of my PhD project:
http://pec.dev.java.net/
I have a couple of questions though:
1. Do you have any firm dates for release? You said it would be out shortly in your Blog.
2. Can it only be used inside Netbeans or can it be stand alone? In particular can it be called from an apt annotation processing class?
Keep up the good work,
Howard.
Posted by: hlovatt on August 03, 2005 at 07:49 PM
-
Here is the Jackpot project page.
Posted by: tball on March 15, 2006 at 04:02 PM
|