Tom Ball's Blog

Community: NetBeans Archives

Elephants and the JavaFX Script Compiler

I don't know what it is about elephants, but they sure work well in analogies. Whether we are ignoring them, seeing pink ones or trying to sell white ones, elephant analogies seem to communicate ideas well. An elephant analogy came to me when I was recently grilled about exactly when the JavaFX Script compiler team will deliver our first milestone release. "I can't give you an accurate date," I said. "It's like pushing an elephant through a door*; until a critical mass makes it past the threshold you just don't know when you'll be finished. Once you pass that threshold, though, the rest happens quickly and in a manner that can be more accurately predicted." And then the tension in the room broke, as I think everyone has been in that situation sometime in their respective pasts.

In a way, this compiler project has turned out to be very similar to some of the GUI toolkit ports I've worked on in the past. We're making lots of measurable progress, which anyone can monitor in our test/features directory; for example, we recently implemented support for our "big three" language hurdles: sequences, multiple inheritance, and functional attributes (aka closures). Since the primary focus of JavaFX Script is as a domain-specific language for Rich Internet Applications, however, few people want an early access release of what we have so far -- like GUI toolkits, it doesn't get interesting until you can start working visually. So even though the JavaFX Script UI runtime needs an overhaul, we're porting it as is for the first release so those necessary GUI features are there.

Another similarity this project has to a GUI port is that most graphical toolkits have a few core components that depend upon most of the rest of the toolkit; call those classes Widget, Component, JComponent, Window, (graphic) Node, it doesn't matter -- there are so many benefits to sharing code between GUI components that these elephant-sized classes are just part of the GUI toolkit territory. So porting a GUI toolkit means that often there will an excruciating period where there is little visible progress as you work through all the dependencies, and then your first window appears, and then most of the remaining toolkit seems to just fall into place quickly. That's what happened many years ago when I was part of a team porting Presentation Manager from OS/2 to CTOS (which was about as unlike OS/2 as could be possible in those days). For several weeks, we slogged along without any visible progress (as voiced daily by our frustrated management), then we finally got the login panel showing and, in less than a week, all of the core applications were up-and-running. That login application was the critical part of our elephant, since the closure of its toolkit requirements encompassed most of the system. It wasn't really the login panel itself, of course, because whatever application is chosen first will be the hardest.

This is all a long-winded way of saying that we are really close toward delivering our first milestone release, but when the exact date will be remains unknown. If anyone is interested in monitoring our progress, check out our JIRA issue tracking system (courtesy of Atlassian), and/or subscribe to our developers alias (comments from experienced elephant pushers are welcome). Once we hit this first milestone, we'll be able to provide a much better road map for the remainder of this release.

*No elephants were hurt during the writing of this blog entry.

The Birth of the JavaFX Script Compiler

Today a new JavaFX Script compiler incubator project, openjfx-compiler went live. Yes, it has source code, issues, mailing lists and a wiki, but the compiler itself actually does very little right now (although Chris Oliver did offer a nice tease). So why open it now? The answer is that our team wants to open not just its source, but the design and development of the compiler itself. We are also asking for feedback on the JavaFX Script language to make it fully specified and compilable.

If you have an interest in watching or participating in a compiler for JavaFX Script, please join our project and help shape its future. If the past couple of months is any indication, it's going to be fast, furious, and fun!

"Advanced Java Refactoring" JavaOne Slides Available

Today I gave a talk at JavaOne titled "Advanced Java Refactoring: Pushing the Envelope" to a packed room, and just pushed a PDF of the slides to the Jackpot project site. Unfortunately I mismanaged the talk's time, spending too long on the demo and had to blast through the last (and, IMHO, the most interesting) slides. My apologies to those in the audience for not doing a better job by them.

It was great to see the continued interest in Java refactoring as its state-of-the-art is improving so rapidly among all the Java IDEs. I've come to rely on the 6.0 NetBeans Java editor over the past several months, in large part because many common refactorings and some new ones are fully integrated into the editor, instead of hiding in a separate Refactoring menu. Traditional refactoring improved my productivity when I first started using it many years ago, but this tighter integration is like strapping booster rockets to my chair. So my talk wasn't about the cool refactorings I'm starting to work on, but instead about how Java tools are changing the very meaning of refactoring and taking it much farther than it was first envisioned.

When debating language strengths, one thing Java engineers may be overlooking is how much Java's being a strongly-typed and statically inspectable language determines how refactorable it is. For example, the bytecode verifier that has been a part of the JVM since 1.0 puts several limits on what is considered valid code, since the verifier has to model that code accurately in order to verify it. Therefore to a certain extent, any language that can run on the JVM can be modeled fairly well. But Java adds a lot of semantic information which makes much richer models possible than with most other languages, so that language-aware tools like refactoring editors have much more information to work with when working with Java. It also avoids features that undermine modeling, such as C preprocessor abuse.

Lately I have been disappointing Sun's C and JavaScript tools engineers who want to leverage the NetBeans IDE's new Java refactoring engine (much of which is based on Jackpot), because the only answer is "no can do" -- their languages can't be statically modeled as completely as Java can. So if you get into a late-night pub discussion about how Java is so last century and that dynamic languages will soon rule the world, pick some of your favorite refactorings (those that really improve your productivity) and ask if their language/IDE supports them. Now, there are some brilliant people working on world-class languages, but they will have trouble competing with engineers leveraging the rich Java models generated by javac, Jikes, IntelliJ IDEA, and other Java tools. I suspect improved refactoring is one way Java will remain viable for many years to come.

My JavaOne Talk on Advanced Refactoring

• The acceptance notifications have been slowly trickling in (and as far as I know are not finished yet). Although I heard rumors that some speakers were notified in early February, I was notified less than a week ago.
  
  
• Last year there were many blog comments from people who felt such announcements were either boastful (if accepted) or whining (if not). "Once bitten, twice shy" so I expect some accepted speakers are keeping quiet.
  
  
• The talks most developers want to hear are from other developers, who tend to be introverted and so are lousy at promoting themselves. After all, anyone who prefers spending half their waking hours staring at a screen can't claim to be outgoing! In my case, it's easy to talk publicly about the technologies that excite me, but it's much harder to talk about personal news.

Jackpot just open-sourced? But I thought it already had...

• 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.

Yet Another "5 Things" Blog

1. I never had a formal university education (just college courses whenever they look interesting). Although my high school was rated in the nation's top-ten public schools, their guidance counselors ... how to put this delicately ... sucked, perhaps because it was so easy for their college-track students to qualify for the top colleges. My strengths were in math and English, and was told that since people with advanced English degrees have few career prospects (a common question asked by humanities graduates is "And do you want fries with that?"), my two best job choices were to either join the NSA or become an actuary for the insurance industry. As a long-haired hippy then (we didn't call ourselves hippies, though), neither becoming a government spook nor spending my life calculating when people will die sounded very appealing. If only someone had clued me into how the University of Illinois' math department was starting to teach programming (later creating the first graphical web browser), my life would have taken a much different turn.


2. I was a union steelworker. After finishing high school and before music paid the bills, I worked for a couple of years at AMSCO in Chicago Heights, Illinois, first as a grinder and then finished an apprenticeship as a maintenance mechanic and electrician. This wasn't some clean steel-slitting operation, but a down-and-dirty foundry specializing in very big castings. (AMSCO in the USA no longer does cast steel, but you can see the sort of pieces we created on the AMSCO Cast Products (Canada) site.) After you have worked here, no programming job can be considered real work.


3. My first job was as a professional boy soprano (I'm a baritone now). Yes, back eons ago (the early sixties) it was politically-correct for churches to have all-male choirs, with boys singing the soprano and alto parts. At the peak of the baby-boom there were enough candidates that you had to try out for the best choirs and be both talented and dedicated to be accepted. St. Mark's Church had an exceptional choir in those days, and for some reason I made the cut. It was hard work, in part because the boys had to memorize all of our music; my guess is that there were too many delays getting twenty boys' sheet music organized during church service. It was great training, however.
   
   Professional? Yes, actually: because the boys practiced Tuesday and Wednesday afternoons (Thursday evening and Sunday morning practice for the full choir) we were paid anywhere from $1.50-$3.00 a month based on attendance and seniority. That may not seem like much ("mouse nuts", as they said in the foundry), but that is equivalent to $12-$20 in today's dollars. Nice pocket change for a nine year old back then.
   
   I was part of the choir for two years, but timed that tenure poorly: a year before I joined they recorded a record album, and the year after I left they performed a concert tour in Europe. Still, the most spiritual moment I've ever had was hitting the high-A in Handel's Hallelujah Chorus with a thirty-two foot pipe organ blasting behind me on Easter morning.


4. I was a semi-professional singer and bass player in a touring rock band based in Denver, Colorado. I say "semi" because we never made much money after our expenses, but it was mostly a full-time commitment. This was in the mid-seventies when "accoustic rock" became very popular, especially in the western states. Three-part tight harmonies with a mix of accoustic and electric instruments; although much of our material was original, we were in a similar genre as the early Eagles and Pure Prairie League. BTW, it's quite mentally challenging to sing lead while playing a counterpoint bass part. I think learning to manage two distinct thought processes concurrently helped develop my multi-threading coding skills later.


5. I have an evil twin. You'd think having an unusual name, a professional focus on static analysis tools, singing in a choir and playing bass guitar would define me as a unique individual, but Microsoft and Sun each employ such "individuals". We had dinner together awhile back and tball(2) turned out to be a nice guy, so he's really only evil by association. However, his first research job was with Bell Labs, whose parent company back then had a logo that looked suspiciously like the Death Star -- so maybe the soap operas are on to something with all their evil twin plots.

Get Medieval On Your Code

In the past few years, Java has finally started to catch up with C on this front. Third-party static checkers like FindBugs and PMD are now freely available and are easily integrated into a build. In Java 5 the javac compiler added the -Xlint option with several types of checks, which were significantly expanded in Java 6. The Jikes compiler has a similar option called pedantic compilation (+P). All of these tools allow you to enable/disable different types of tests, and unless you strongly disagree with certain tests I recommend that you turn on all the warnings you can.

Sometimes you need to suppress one or more warnings for a specific block of code. Java 5 introduced the SuppressWarnings annotation to enable you to do this, but javac ignored it in that release; happily, it is now recognized in Java 5, update 6 (1.5_06). One big advantage of globally checking for a type of potential error and suppressing it in specific places is that the SuppressWarnings annotation serves as documentation that you really intended to do this questionable practice. For example, Jackpot's parser outputs a big switch statement for a rule set, which is optimized using case statement fall-through. Since fall-though can be a frequent source of bugs, Jackpot is tested with javac's fall-through checking and with a @SuppressWarnings("fallthrough") for this specific method -- that way if there are fall-through bugs elsewhere they will be flagged. Turning warnings into build-stopping errors has also been enabled in Java 6 via javac's hidden -Werror flag (just like the C compiler's). Jikes has the +Z2 flag to do this, and recently it added a -Werror equivalent to be command-compatible with javac.

For NetBeans projects, it is easy to set these flags by right-clicking on the project, selecting its properties, clicking on the Compiling panel and putting them in the "Additional Compiler Options" field. It can be a pain changing all of your Ant build files to do this, however. You can set this property globally, however, because NetBeans projects have a javac.compilerargs property hiding in the nbproject/build-impl.xml file we can use. To set this for all projects which have this property, add this line to $HOME/.antrc (which probably doesn't exist):

ANT_ARGS='-Djavac.compilerargs="-Xlint:all -Werror"'

Separate static checker tools can be integrated into your build as well. Ant tasks are available for both FindBugs and PMD. Both tools have a failOnError parameter which can be set true so the build stops if a warning is issued. Both of these tools support the SuppressWarnings annotation, too.

Now, those of you who are really hard-core will point out there are many other ways you can stop coddling your build and make it cough up its bugs. You are right, and in future blog postings I'll investigate other ways to get medieval on your code.

Hacking Open Source javac!

This is great news for anyone interested in Java performance, as the world now has full-access to both the static (javac) and dynamic (HotSpot) optimizing compilers from Sun's Java implementation. Remember back when everyone laughed at the prediction that with dynamic compilers like HotSpot, Java performance will eventually surpass C++? This is starting to happen now with the continued performance gains in Java 5 and soon Java 6. My hope is that an open-source HotSpot and javac will encourage the world's best and brightest to augment the excellent work of the JDK team to drive Java performance further.

So how can you start contributing? The first step is to download and build the source using the links above. But wait! There is an easier way to work with javac's source: NetBeans has a brand-new nb-openjdk project which makes downloading and building the javac source painless and productive. My guess is that this project will grow to support the HotSpot project as well as the rest of the JDK's components as they are released. Happy hacking.

Hacking javac

hack (hăk) n., A non-obvious solution to an interesting problem.

This definition is on the front of a tee-shirt I have from O'Reilly Media to promote their Hack Series, which includes one of my favorite books, Swing Hacks by fellow java.net bloggers Joshua Marinacci and Chris Adamson. The reason I like the Hack Series is that even for subjects you know fairly well, these books describe interesting solutions which I hadn't realized. It's that constant discovery of "non-obvious solutions" which has kept me so interested in programming over the years.

Take compilers, for example: they just compile source code into object code, right? Hacking them is generally frowned upon because as Ken Thompson discused in his ACM award acceptance speech, Reflections on Trusting Trust, they are a great place to hide a trojan horse. But if the compiler is designed to function as a tool library, as javac is, much more interesting (and benign) hacks are possible. Mustang (excuse me, Java 6) has three related API which all Java tool hackers should check out: JSR-199: Java^TM Compiler API, JSR 269: Pluggable Annotation Processing API, and the Tree API (com.sun.source.tree and com.sun.source.util).

The Compiler API is deceptively simple: it gives you the ability to programmatically invoke javac (actually, any tool that implements the Tool interface such that ServiceLoader can find it) and compile one or more source files to class files. That's nice if you are writing an appserver container, perhaps, but not very hack-inspiring, right?

As Robin Williams said in the Disney cartoon Aladdin (I have small kids), "Wrong! But thanks for playing." The first hack leverages JSR-199's DiagnosticListener interface, which lets you listen to the errors and warnings created by the compiler. NetBeans uses this technique to display errors while you are editing Java sources; compilation is run regularly in the background but only the diagnostic events are used. JSR-199 improves on the old trick of parsing error strings with Diagnostic instances, which provide accurate source position information, and locale-independent error IDs with locale-specific error text.

Still bored? How about creating your own scripting language? Rather than write a complicated intepreter, write a (hopefully) simpler compiler which outputs Java source files. Then use the Compiler API with a custom ClassLoader to dynamically load these classes on-the-fly, as if they were interpreted. Think the process is slow? The Jackpot rule language parser generates Java sources and uses this hack to compile them (look in $HOME/.jackpot). We used to conditionally compile scripts only if they had changed, but found that javac is so fast that caching didn't make a difference (we just keep the files for troubleshooting). If you don't want to write anything to disk, a related hack involves implementing the JavaFileManager interface to use memory instead of files -- javac doesn't care about files since it only uses streams supplied by whatever JavaFileManager implementation you provide.

JSR-269 is officially the "Pluggable Annotation Processing API", and while it does that very well it also enables lots of other hacks. A general way to think of JSR-269 is that it gives you access to all of the types and elements (symbols) in any set of source files, not just its annotations. Its javax.lang.model.util package has easily extendable visitor and scanner base classes which can be used by tools to inspect projects at the semantic level. One group of tools which can use this hack include error checkers that validate design rules, such as that any class which extends Object.equals() also extends Object.hashCode(). One advantage of using JSR-269 types and elements rather than your own parser for these sorts of tests is that while you can infer many properties from a parse tree, the javac semantic model knows the correct properties.

If you want to dig deeper than types and elements, the Tree API makes this sort of hacking simpler. Because the Tree API is not defined by a JSR, the JSR-199 and JSR-269 APIs cannot directly refer to it. So if you just look at those API, it seems impossible to inspect class members beyond their declarations. The semi-secret hack here is that javac's javax.tools.JavaCompiler implementation returns a CompilationTask instance which is also an instance of com.sun.source.util.JavacTask. This class is much more interesting to tool hackers, since it give you access to the parse trees and all JSR-269 information, plus control over javac's execution. Don't need to generate class files? Just invoke JavacTask.analyze() instead of JavacTask.generate(). This class also provides access to the Types and Elements utility classes, which make hacking even easier. So if you know you are using javac as the tool provider, you can just cast the task instance to JavacTask and have fun.

These API provide a read-only model of Java source code, so it is difficult to modify source code programmatically (you can overright the files, of course, but comments and formattting get blown away). For hacking source files without angry mobs coming after you, you'll want the Jackpot API, which extends these API to provide model transforming and formatted source rewriting. These four API work together to define a toolkit to create just about any Java language-aware tool. What sort of "non-obvious solutions" can you create with them?

Is Writing Code a Career Limiting Move?

¡Hola, del Mar Caribe!

See You at JavaOne

If you are interested in Jackpot, there will be an announcement regarding it at NetBeans Day. Thursday morning I'll be presenting Creating and Deploying Custom Jackpot Queries and Transformers (TS-1278), which will describe how developers can create their own bug-searching and fixing tools and share them with others or deploy them within an engineering organization. Friday, there will be a short Jackpot demo at James Gosling's keynote. (Looking up the URL, I just found out Scott McNealy will be hosting that keynote, too. I better "kick butt", as he likes to say, during the demo!)

If you are attending JavaOne, please check out these "Jackpot sightings" if you can. If you see me rushing down the hall, join the rush and introduce yourself.

A Little Language

The Power of Community

    Although, what would really be neat is

    { $p$; $v = $e; return $v; } => { $p$; return $e; } :: declaredIn($v, $p$);
 
    which seems possible in principle, but not with the current rules language.

• I got a simple, but very useful, enhancement suggestion. Especially with tools, a developer really isn't the best person to know what parts of a project are useful and what it is missing -- potential users of it are.
• Even better is that I got a free code-review from some smart engineers who had never seen the language before. This is proof that good programmers can write in any language!

Jackpot Early Access Available

Jackpot's Coming (Finally!)

• 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.

NetBeans 5.0 is Making Me Grumpy

The NetBeans 5.0 beta just released, with a slew of new features that improves application development and therefore, can make old-timers grumpier. The feature that makes me grumpy is one many NetBeans users won't care about: developing NetBeans Modules and Rich Client Applications is now much, much easier than in previous releases. Core tasks that once took me days to learn are now boiled down to clear, easy-to-understand wizards. Extending NetBeans is no longer limited to the core set of engineers dedicated (and masochistic) enough to devote the necessary effort to use this API effectively.

As a recovering engineering manager, it's been a pleasure watching the "apisupport" team design and implement this critical feature. First, a small team was created and, as much as possible, dropped out of sight from the rest of the engineering group. As NetBeans management learned several releases back, rewriting core functionality requires isolating the team from corporate antibodies, which can kill innovation that threatens existing systems.

Next, NetBeans lucked out and hired an exceptional doc-writer, Geertjan Wielenga. I normally don't single out individual team members for praise since engineering is a team sport, but Geertjan's contribution was critical because he didn't function like a normal doc-writer. Maybe it only is true at Sun, but here most writers are forced by their heavy workloads to avoid getting too involved in early product development, preferring to wait until the design is finalized so as to avoid having to drastically rewrite their work. Geertjan, on the other hand, jumped right in with no previous NetBeans API exposure (as far as I know) and quickly started writing several short tutorials (found here), bombarding the developers with questions and then forwarding frequent drafts to the team for review. Because the development engineers were trying to make NetBeans API development easier, his questions helped shape the various wizard designs (if a developer has to ask too many questions, the current design isn't working). Other equally good doc-writers might ask similar questions yet don't impact the product's code as much, because they waited until the design was frozen when they started writing documentation for it.

Geertjan's tutorial code also showed lots of places where NetBeans was unnecessarily burdening module developers by requiring hand-written, boilerplate code. The development engineers therefore reviewed each tutorial with an eye for how they can shorten or even eliminate the tutorial with a wizard design, because documentation also functions as design criticism (i.e., good designs shouldn't require much explanation). Geertjan then quickly made massive rewrites and eliminated a lot of code as the API support improved. His impact on the project therefore can't be weighed by how many words made it to the public website. I wish more doc-writers and QA engineers were actively engaged in the initial design and development process, but suspect it is a management scheduling problem rather than a lack of interest or commitment.

My biggest complaint? I wish this work had been done six months ago, when I started working on making a NetBeans module which uses Jackpot, as it would have saved me literally weeks of work. So be warned that I may get grumpy about complaints about how hard module development is. <rant>"It took you a week to extend NetBeans 5.0? Why that's nothing! In my day we spent months staring at source files 'til our eyes bled, but we were happy to do it."</rant>

Java 5's Varags Clean Up Reflection Code

Yesterday I was updating a Factory class which uses a ClassLoader and Java's reflection facility to separate a public interface (JackpotEngine) from its implementation (Engine), and got an unexpected compiler warning about vararg misuse calling Class.getConstructor(). Say what? I wasn't anywhere near a printf()! Here was the code:

    public static JackpotEngine createEngine(String jarPath, AppContext appContext) throws Exception {
        ClassLoader loader = new JackpotClassLoader(jarPath);
        Class c = Class.forName("org.netbeans.jackpot.Engine", true, loader); // NOI18N
        Class[] argTypes = new Class[] { AppContext.class };
        Constructor con = c.getConstructor(argTypes);
        Object[] args = new Object[] { appContext };
        return (JackpotEngine)con.newInstance(args);
    }

    public static JackpotEngine createEngine(String jarPath, AppContext appContext) throws Exception {
        ClassLoader loader = new JackpotClassLoader(jarPath);
        Class c = Class.forName("org.netbeans.jackpot.Engine", true, loader); // NOI18N
        Constructor con = c.getConstructor(AppContext.class);
        return instance = (JackpotEngine)con.newInstance(appContext);
    }

    public static JackpotEngine createEngine(String jarPath, AppContext appContext) throws Exception {
        ClassLoader loader = new JackpotClassLoader(jarPath);
        Class c = Class.forName("org.netbeans.jackpot.Engine", true, loader); // NOI18N
        Constructor con = c.getConstructor(AppContext.class, String.class);
        return instance = (JackpotEngine)con.newInstance(appContext, jarPath);
    }

Can't Tell the Forest for the Trees

JFind: a simple jar file locator

So a while back I wrote a simple command-line utility called JFind, which is now in the NetBeans repository here. It's a single, simple class, which relies on the java.io and java.util.zip packages to do the heavy lifting. Just specify the class or package you want to find and a directory to start your search, and it will report the jar file or path that defines it.

For example, to find which jar provides org.openide.ErrorManager in a NetBeans distribution, run:

    java -jar jfind.jar org.openide.ErrorManager dist

    java -jar jfind.jar -p javax.crypto JDK-directory

Project Jackpot at JavaOne

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.

This work is licensed under a Creative Commons License.