 |
Jackpot just open-sourced? But I thought it already had...
Posted by tball on January 25, 2007 at 03:31 PM | Comments (7)
After months of slogging through Sun's Open Source Review process, last night I committed Jackpot's source to the NetBeans public CVS repository. If you want to browse it, follow the directions in the NetBeans CVS Access page, specifying "jackpot" as the module to check out.
You may be in for some disappointment if you do this, however, as all these source files provide is IDE integration for Jackpot, its UI, and rule file editor support. Where's the beef? Where is the code that does pattern matching on compiler ASTs and transforms them? Where is the source rewriter? WHY IS SUN YANKING MY CHAIN AGAIN!!! (I really get email like this occasionally.)
Now take a deep breath and relax. The truth is that Jackpot started life as a research project prototype which found some useful conclusions, including:
- javac can be a great Java model generator for other Java tools;
- a re-entrant javac turned out to be really fast when run as a background task; and
- you can do some really gnarly-yet-safe editing with it.
So the Jackpot project passed much of its source to the javac team to make it re-entrant and its model useful for other tools for Java 5.0 (mostly James Gosling's work), and worked with the javac and NetBeans editor teams to help define the Compiler API released in Java 6. In a very real sense, you were using some parts of Jackpot when compiling with Java 5, and the associated source code is in the javac code recently made public.
The Jackpot piece most interesting to compiler junkies was released a few months ago. The new Java editor, which is coming in NetBeans 6.0, is based on the Compiler API and the transformation engine from Jackpot. That engine was quietly included as part of the new editor's release to open-source last October:
To browse the engine's source (and the Java editor enhancements), check out the "java/source" project using the CVS instructions above.
Yesterday the remaining parts of Jackpot were released to open-source, the ones no other project needed to publish first. The project is now a lot smaller than when we first transferred to the Developer Products Group (aka Tools), but its integration into the javac and NetBeans Java editor source bases will ensure its wider use throughout the Java community.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Tom--IIRC, Jackpot is dependent on a kind of index of the files in your project, to speed up processing of the AST--is that correct? Is the indexing built into the NBM or can it be (easily) extracted? Thanks, Patrick
Posted by: pdoubleya on January 28, 2007 at 01:10 PM
-
No, today javac/apt/jackpot all run the source through the compiler's front-end using the classpath to resolve external type references. There is no index file, but you do need to have a "build-able" project to get useful information.
In NetBeans 6.0 the Java model will cache type-resolution information to improve performance. This is a sort of index (the cache entries are really classfiles without code segments), but one that is built and rebuilt on the fly as the project changes. Jackpot will soon move to using this cache so it can scale better to larger projects.
If you run 6.0 and want to browse this cache, it's in your $HOME/.netbeans/dev/var/cache/index/.
Posted by: tball on January 28, 2007 at 10:16 PM
-
Tom, is there an NB6.0 build now that you'd say is usable with jackpot etc bundled? I've got several old NB5.0 modules that use the javamodel from those days and which I need to convert to 6.0. I'd like to get that done, and be able to use 6.0 so that I don't have to maintain both versions of the modules for my use vs others.
Posted by: greggwon on January 30, 2007 at 06:33 AM
-
The daily builds should be usable now, provided you then install the Jackpot Developer module from the Development Update Center (or do your own build and include the jackpot modules). There may be some API "jitter" for awhile, however, as jackpot is about to undergo API review. If you'd like to participate (or just watch), add yourself as a CC to issue 93224. Here is the API Review process description.
Posted by: tball on January 30, 2007 at 07:47 AM
-
Hi Tom, Can I say that with NB6 Java editor based on the compiler API, and javac compiler open sourced, I can create my own version of javac parser/AST builder, adding small language extensions (like var l = new ArrayList()) through Jackpot, but with compatible AST, then the new syntax will be straight accepted by the NB6 Java editor UI? Really great if so.
Posted by: complystill on February 25, 2007 at 10:43 PM
-
Yes, that's true in theory. However, the NetBeans editor team has been making substantial improvements in the compiler's error recovery which haven't all been incorporated into the main javac source base (soon). To really be useful in an editing environment, where the source code being edited is broken more often than not, a compiler needs to recover more gracefully from errors than a command-line tool does. So be prepared to regularly merge with the javac base in order to get these improvements as they appear.
Posted by: tball on February 26, 2007 at 06:52 AM
-
Great! I'm a blue fan of eclipse importantly because of its incremental java compiler, tightly integrated into the IDE. But now javac is heading the same direction now, and may be even greater, since one improvement benefits both the cl javac, the NB IDE, and even Ant scripts. This is much harder for eclipse to achieve, especially for experimental language variants, where NB6 projects should be easily configured to use a custom javac.jar as the compiler and model parser.
And I don't think SUN will lose control of the Java language when more people are adding new features to their own variants, by providing complete building systems with GPLed derivations of javac. Quite the contrary, Java is still a trademark held by SUN, and the language spec is still under control of JCP, so really useful and feasible features (like GJ) can be simply merged into the spec and SUN version, legally governed by GPL. There will be just more candidates.
I think this is one of the reasons why IBM is against GPL for Java, eclipse may lose its domination of Java IDE, and confounded to follow up rapid evolutions of the language.
Posted by: complystill on February 26, 2007 at 06:07 PM
|
java.net RSS Feeds
