Project History
===============
What is now CongoCC originated as a "fork" of the well known `JavaCC parser generator `_. JavaCC (short for *Java Compiler Compiler*) is a parser generator that was developed at Sun Microsystems in the nineties, in the very early days of Java itself. Development had been dormant for at least 4 years (possibly more) before Sun decided to make the code available under an open source license in mid-2003.
Five years later, in 2008, Jonathan Revusky, who had been an end-user of JavaCC since 2001, and used it to implement the popular `FreeMarker template engine `_, downloaded the JavaCC source code mostly out of curiosity. There certainly was no intention of creating a "fork". The idea was that if any improvements were made, they would be donated back to the JavaCC community. This, of course, is how open source normally works. (Or is *supposed* to work.) What happened then is that in the space of some months, Revusky made certain very clear improvements to the tool, implementing the ``INCLUDE`` and ``INJECT`` features. Revusky's JavaCC "fork", which was called *FreeCC* at that time, only came into existence because, when he duly tried to donate his improvements back to the JavaCC community, he was met with intransigence. In fact, the project "insiders" adamantly refused to review his work.
Probably more fundamentally important than the new features of ``INCLUDE`` and ``INJECT`` is the fact that Revusky refactored the codebase to use a template engine (FreeMarker obviously) to generate Java source code. (JavaCC used, and basically still uses, a series of ``out.println(...)`` statements to generate Java code.) Though the JavaCC project insiders affected that they saw no value in it, refactoring the codebase to use a template engine really was absolutely essential: it created a basis on which progress could be made. Without that, the code was, to all intents and purposes, totally intractable, and even with the best of intentions, nothing could be done with it. It was just too bloody hard! So, no progress had been made in the project since it was open-sourced 5 years before that point. Fast-forward to the present day, 18 years later (23 years after Sun open-sourced the code) and the legacy JavaCC feature set (and more to the point, its *bug set*) is essentially unchanged. (That *bug set* included (*and still includes*) glaring issues like the fact that nested syntactic lookahead was, and still is, ignored, or the fact that lookahead does not work correctly in conjunction with lexical states.)
It really should be noted that referring to this branch of work, originally labelled *FreeCC*, and nowadays as *CongoCC*, as a "fork" is actually rather dubious because the term "fork" surely implies some *bifurcation* of effort. In fact, there never was any such *bifurcation*. Even taking into account the dormant period from 2009 through 2019, the codebase originally labelled "FreeCC" is the only genuine branch of development that has ever existed -- specifically, a serious attempt to do something meaningful with the JavaCC source code that Sun Microsystems made available in 2003. (That is why, throughout this exposition, the term "fork" has scare quotes around it!)
However, be all that as it may, it is very hard to gain traction for the "fork" of a well known software project like JavaCC -- even when the so-called "fork" is the only real branch of development! Though *FreeCC* did have a small-ish user community, Revusky drifted away from this work and the last *FreeCC* release was at the very beginning of 2009.
The story picks up again a bit over a decade later when, for some imponderable reasons, Revusky picked up the *FreeCC* code at the very end of 2019. In early 2020 he renamed the project to JavaCC21 (the 21 was not a version number but meant to indicate that this was a JavaCC for the *21st century*) and implemented a series of new features and bug fixes. The very first goal that was set was to update the internal Java grammar to support a more up-to-date version of the Java language. After all, revolutionary changes had occurred in the preceding decade. It was considered essential, to get to the JDK 8 level, which is when lambdas were introduced. (At that point in time, JDK 8 was already 5 years old.) Within a couple of weeks of picking up the work again, FreeCC (as it was still called at that point) included a Java grammar for Java up to JDK 8. By March 2020, the grammar was updated to support up to JDK 13, which was the most recent version of Java at that point in time. (As of this writing, mid-2026, the legacy JavaCC has no support for any new Java language features post-JDK 7.) A major milestone was reached when the longstanding bug that nested syntactic lookahead was ignored was finally squashed. See ``_.
Aside from that, the rather clunky syntax of the original JavaCC was streamlined and the cleaner looking ``SCAN`` and up-to-here notation were introduced. In 2021, Vinay Sajip got involved in the project and implemented the ability to generate parsers in Python. And later in C#.
In late 2022, it was decided to rename the project since it had evolved so far from its JavaCC origins that it seemed to make little sense to keep calling it that, albeit with the "21" appended. The name "CongoCC" originated in thinking about names that are connected with trees (the product of parsing being an *abstract syntax tree*) and is an allusion to the Congo Rain Forest, which is (at least according to Wikipedia) the world's second largest forest. The world's largest forest is the Amazon Rain Forest but, for obvious reasons, it did not seem that putting "Amazon" in the name would be a good idea. Aside from the rather tenuous connection with trees (*the real ones!*) CongoCC has the same relationship with West Africa that Java (or JavaCC) has with Indonesia, or that the online retailer Amazon has with South America, or that Microsoft has with erectile dysfunction -- i.e. *none at all*. The name was chosen because it was considered (*rightly or wrongly*) that it sounded *cool*.
Now, to get back to the technical realm, with this *Congo* rebranding, the project largely broke the backward compatibility constraints. During the period when it was still called *JavaCC21* great pains were taken, basically as a courtesy to existing JavaCC users wishing to migrate, to keep it as backward compatible with legacy JavaCC as possible. That is no longer the case. The rebranded CongoCC no longer supports the more cluttered legacy syntax from JavaCC.
The current focus is on:
- Polishing off fault-tolerant parsing
- Polishing off the "polyglot" features, so that non-Java languages finally are first-class citizens in the system. (They aren't quite yet.)
- Documenting the overall system (This very page is part of that effort!)