Patience is a virtue? I never really learned that growing up, and impatience has served me and most of my fellow developers much better in our careers. So it's been a frustrating time since JavaOne lining up my ducks (an expression which probably doesn't translate well, but visualize how hard that would be) to make Jackpot available. Yesterday we had a big breakthrough, though, with marketing buy-in for a phased release plan. "O frabjous day! Callooh! Callay!� He chortled in his joy."

There were two important requirements for a Jackpot release: provide a public, stable API that doesn't reference any javac internals, and fully integrate it into the IDE environment. The good news is that the read-only Java model developed by the javac and apt teams is now almost finished and Jackpot's API has been converted to reference it. Yes, the JCP process is painfully slow for those of us who lack patience, but both teams have delivered great work that should stand the test of time.

I have been moving more slowly on the IDE-integration front, but things are looking up. Because of the focus on rewriting the engine to use the new public APIs, I haven't had time yet to write any killer transformations. The early release will therefore just have sample commands which demonstrate Jackpot's potential, so expect some disappointment when you first try it. Its UI is also much too modal: you start a "session", invoke queries and transformers, then end the session to save the changes. To make matters worse, if you edit any files in the middle of a session, the session is invalid but you won't be notified of that until you try to save. My apologies for creating such a bad interface, but it's temporary.

This week's other good news is that because NetBeans 5.5 is now in preview, I will finally get some help from the overworked NetBeans UI team. We've only had one meeting so far, but I left with several excellent ideas for better integration of Jackpot and thus a better UI. Let my mistake be a warning to others: just because you are a good coder (or even a former Swing architect) doesn't mean you are a good UI designer. I never thought I was very good at design, but this meeting reinforced that awareness of my limits -- I guess once a systems engineer, always one.

So the current plan (don't call it a schedule) is as follows:

• Early-access release in a week or two, as soon as I can pull it all together for distribution. This release will be focused on engineers interested in exploring Jackpot's rule language and API so they can write their own queries and transformation (you can join the project here). We're looking to attract smart engineers who want to create and contribute transformations for the rest of the world to use. As I said, the UI will be rough and the included set of commands very limited, so this release won't be of much interest to folks who just want to use canned commands. This first release will just be NetBeans binary modules, since I don't want to hold up access while going through the open source process steps. Source code for the distributed queries and transformers will be provided as samples, however.


• Because we'll be distributing Jackpot via the NetBeans Development Update Center, there will be frequent updates depending upon community feedback. We'd like as much feedback and response as possible, similar to Swing's pre-1.0 bi-weekly updates that proved so useful. Source code for Jackpot's IDE integration and rules editor modules will be made available in the NetBeans CVS repository during this period.


• A beta release of Jackpot, with the new UI and richer command suite, is targeted for the JavaOne 2006 timeframe. Because this will be a more stable release, it can be distributed via the NetBeans Beta Update Center and run on NetBeans 5.0 or 5.5.


• Jackpot 1.0 in early fall 2006, depending upon feedback and meeting normal release requirements.

I want to thank you for (im)patiently waiting, and look forward to your comments, suggestions, and criticism once Jackpot is available.