Why the Bifurcation of Effort?

JavaCC is a Java based tool of 1990's vintage. As I (Jon Revusky) understand it, it was originally developed in 1996 in a company called Metamata. JavaCC was free as in beer, but was not open source.

Now, first of all, let's put this part of the timeline in perspective. JDK 1.0, or now called Java 1, was released in January of 1996. JDK 1.1 was a year later, in February of 1997. At the risk of dating myself, I was involved with Java pretty much from the start. I believe the first JDK I downloaded (it took forever over a dial-up model connection!) was JDK 1.0.2. Inner classes were introduced a year later in JDK 1.1. But this was still Java 1. Java 2 (or JDK 1.2 it was called at the time) was released at the end of 1998.

Doubtless, the original JavaCC project could have benefited from the collections library introduced in Java 2 but that came out nearly two years later, at the end of 1998. Well, the key point to take away from all this is this: the entirety of the legacy JavaCC codebase was written against Java 1, the oldest, most primitive version of the Java language.

Now, Metamata, where JavaCC was originally developed, was acquired by some other company called Webgain, that was in turn acquired by Sun Microsystems. That is how Sun came to own the copyright to JavaCC. As best I understand, it was never internally developed at Sun. At least, nothing significant was done with it. As best I can determine, there was no active development on JavaCC after 1997, more or less. By the time Sun Microsystems released the code as open source in 2003, it was an orphan project on which nothing had been done for about 6 years.

The author's involvement with JavaCC began in 2001, just as a user. At this point in time, I became heavily involved in the FreeMarker project, a template engine used in Java mostly in the web application space. The original authors had lost interest and I saw a lot of possibilities of doing something with a template engine. The FreeMarker 1 codebase was a good proof of concept and was actually useful as is. I myself had used it in a number of projects in companies around 1999 to 2000. However, to turn it into a more solid, capable tool would require quite a bit of refactoring. The very first thing to do would be to replace the kludgy hand-written parser with one generated by a parser generator tool.

At the time, I was hardly committed to using JavaCC specifically. At the time it seemed (as it probably does now) that the two main candidates were JavaCC and ANTLR. Though I looked at both, for some reason it was just easier to get going with JavaCC. Pretty soon, I had all of the constructs of FTL (FreeMarker template language, at least, as it existed at the time) specified in a JavaCC grammar and we were able to throw away the old hand-written parser. After that (rightly or wrongly) I never paid much attention to ANTLR.

One aspect of all of this is that, though I became very comfortable I never seriously considered using JJTree. I think the reason was that it just did not seem like there was a clean development process for using it. You would generate all of the AST***.java Node classes and then if you wanted to put some code in those classes, then what? Presumably you would post-edit the generated code

This brings us to the next key point in the timeline.

Sun Microsystems was a company that wanted to position itself as the standard bearer of… well… openness… Open Systems…Open Standards…Open Source. As part of that whole campaign, Sun created a platform for open source Java projects called “java.net”. You can read about it here.

Java.net was shut down definitively in April 2017 because everybody had moved to Github so Oracle (which had acquired Sun) finally turned off the lights. But that is getting ahead of ourselves.

Back in 2003, Java.net was the hot new thing or was supposed to be and Sun wanted to populate it with some sexy open source projects and released the JavaCC code there to much fanfare.