I have decided (tentatively at least) to rebrand my various open source efforts under the name Congo. In line with that grand plan, JavaCC (21) would be rechristened as CongoCC and the major revamp/rewrite of FreeMarker that I have in mind will be known as Congo Templates.

So, why "Congo"?

Well, I guess one could ask perfectly well: why not? The bottom line is that it has a nice ring to it and nobody has proposed a clearly better name! The "Congo Compiler Compiler" or "CongoCC" does have a nice alliteration to it. And it has the same relationship with Central Africa as the Java programming language has with Indonesia. Namely, none at all! (About the same relationship that "Microsoft" has with erectile dysfunction, come to think of it...)

In any case, I have really been feeling that there is a need to move away from the Java-related product naming. With the huge amount of work that Vinay Sajip has done over the last half year, we are really on the verge of presenting the tool as cross-language. So the name "JavaCC 21" will soon make little sense. In any case, positioning the tool as a more advanced, improved version of the crufty old legacy JavaCC has simply not been very successful. The legacy JavaCC still has a significant user base, but, for whatever psycho-social reasons, it is practically impossible to get them to look at an improved version. In any case, pushing a product with that Java-related name in Python or Microsoft land is probably even less promising. So I've been thinking that there is a need for a new name. And this is what I came up with. Well, I like it and everybody I've run this by seems to like it. And certainly, nobody has proposed anything significantly better.

Now, since there is no need for the naming to have any relationship with the product, I suppose there is no onus on me to explain where the name came from. But I might as well recount how the name occurred to me. Since the final product of a parser is typically an abstract syntax tree, I was thinking about names that relate to trees. It seems that I am not the first person to think along these lines. For example, a parser generator tool that I have had in mind to take a good look at is called tree-sitter with a logotype of a treehouse.

Cute, eh? Well, maybe somebody will donate a nice logo to this project!

So, there I was, thinking about trees and this led to forests. We all know (I think) that the world's largest forest (by far) is the Amazon rainforest. However, that seems like it would be a quite ill-advised choice of name for obvious reasons. But once I was thinking along these lines, I asked myself what is the world's second largest forest. I had to look that up and Wikipedia told me that the second largest forest in the world is the Congo rainforest. And this is how I started thinking about the alliterative name of "Congo Compiler Compiler".

So I checked whether the domain name congocc.org was available. And it was. So I duly registered it. Now, as for this discussion forum, I put it up for a variety of reasons. Well, for one thing, after registering the domain name, I felt I should put up some content there of some sort. (Which is probably the main reason I'm writing this initial post!) Now, the project already had a discussion forum, using the well known Discourse forum software at https://parsers.org. However I have had nothing but trouble with Discourse. A lot of people seem to like it but it has always seemed like an over-engineered piece of crap to me. This Flarum thing I'm using now already seems much more promising. I even like it better aesthetically. By the way, if you find the default font size too small (as I do!) just hit Ctrl-+ a couple of times and you should be okay.

So, there it is. If anybody has any thoughts about all this, feel free to chime in. Or just write a post to say hi. It's kinda lonely here at the moment.

    4 days later

    revusky Well, I'm back from my overseas trip, but still tied up with commitments until after 20 March. I'll spend some time looking at recent changes in the code and updates to the C# grammar, and dealing with any issues as soon as I can. I'm intrigued to see if the Congo naming will lead to better community engagement/growth with new users - I don't suppose it will make much difference to existing users of JavaCC21.

    Well, the renaming is not a magic bullet, I'm sure. What really has pushed me towards taking this step is that we're really getting very close to being able to present this to the Python and C# people as something reasonably polished, that they can use anyway, and I don't think the JavaCC naming is very good for that. AFAICS, the Python and C# folks should be presented with this under the new name from the get go. Not that the JavaCC origins of the thing are going to be some closely held secret or anything, but it will, I suppose, end up being kind of like some historical footnote -- and not something that new users, particularly who aren't even Java people, will really give a sh** about.

    As for the Java people, well, we can do the rebranding more gradually, I guess. I have set now as a high priority to buckle down and get a couple of more articles written for Oracle Java Mag. And I don't think I'll change the name in midstream there. In that initial article, it was presented as JavaCC 21 and we'll keep going with that for now. I can see a total rebranding when we have Java, Python, and C# all supported as equal citizens and then, since the resulting tool is not really Java centric any more, we really drop the JavaCC baggage for good maybe. Well, that's how I see things shaping up basically. I'm estimating maybe a six month time frame -- I mean to get the big multilingual refactoring I have in mind fully implemented.

    The renaming is not a magic bullet, but I think now I really feel that people being presented this for the first time, particularly those who aren't even Java programmers, should come to know it via the new name from the start.

    I would like to point out that a major problem of using javacc21 in other projects is the lack of versioning.
    Most java project either require that it can be downloaded from the maven central repository (by version number) or at least that a sha256 checksum can be generated from a download link, to verify that it is a correct version that is being downloaded.
    Javacc21 supports neither.
    That makes it a hard sell to a lot of projects.
    Legacy java is available in maven central and will therefore be the easy choice to go with.

      Gravelbones Most java project either require that it can be downloaded from the maven central repository (by version number)

      Well, people have asked me about this here and there over the past couple of years, but I honestly never got the feeling that this, of all things, was the reason that adoption has been so slow. I mean, for one thing, the whole dependencies management side of Maven, as far as I can see, its value pretty much entirely relates to situations where you're redistributing a library.Then there are different versions of the library floating around and you want to state clearly which one you build and run with, I guess. But the approach that JavaCC (whether the original version or JavaCC) to all intents and purposes dispenses with the whole problem because there is no redistributable component . It generates code that is completely self contained with no dependencies beyond the core classes in JVM. And that was always a quite attractive aspect of the thing, as compared to ANTLR, say, which has a runtime engine that has to be redistributed. In that case, yes, you get into this dependencies management issue, I suppose, because there are different versions of that runtime floating around and presumably this Maven thing does a wonderful job of sorting this all out for you. But when the problem basically doesn't exist for JavaCC in the first place..., Frankly, it is quite unclear to me what Maven or Maven Central is doing for you, what problem is being solved in our case. And, frankly, having a whole bunch of stale versions of the tool sitting around on Maven Central (or anywhere else) is not something that appeals to me particularly.

      Well, I've basically stated as a policy that users are expected to use the latest version. Now, obviously, people can do what they want, but my position is that there is no technical support for anything but the latest version. That's the policy I state here. Basically, I'm saying that there is no need for formal versioning because we're taking the stance that there really is only one version, the current version, and that's that! I guess some people might find that jarring or something.

      Now, all that said, I'm not denying that this is important for some people, but I guess I see this as part of a larger phenomenon -- I mean, there are people out there who have a very, let's say.... formalistic or bureaucratic approach to software development. And a similar *or related issue) is that there are people (frequently the same people, I suppose) for whom it is extremely important that something they use comes from what they perceive as an approved channel. One glaring case of this that I recall distinctly was that back when I created the FreeCC fork in 2008, there was this guy who worked at a major corporation (I won't mention his name) but he was on the JavaCC mailing list trying to get their interest in terms of addressing various issues, most of which were already addressed in my fork, FreeCC. I wrote the guy and had some correspondence with him, but I'm pretty sure that he just never even considered switching over to using FreeCC, because somehow it just didn't come from the "approved channel". Something like that... But that guy was willing to waste quite significant amounts of energy in conversations with the JavaCC people, advocating that they should implement whatever attractive features he needed -- in the full knowledge that everything he wanted was already implemented elsewhere! (Also, unless the guy was born yesterday, he should have known perfectly well that those people were never going to implement anything anyway!)

      So, all of that is a very real phenomenon.

      I guess my point is that the same people, for whom it is so important that something should be on Maven Central, are probably never going to use JavaCC 21 anyway -- at least not until the thing is already very widely known and accepted out there, I guess, and then they'll somehow think that this is something they can use. (And then they'll use it whether it's on Maven Central or not!) And besides, in my experience, once you tell these people that they can't just drop in JavaCC 21 as a replacement and have it work with zero changes to their code, they just walk away from the conversation.

      Gravelbones Legacy java is available in maven central and will therefore be the easy choice to go with.

      Well... quite frankly, anybody who would use something that utterly inferior simply because it's on maven central... I would have serious doubts about that person's competence level. I have to admit that I don't really understand why it would be so important to download something from Maven Central as opposed to our web server. I mean, if you're downloading from the javacc.com server via the secure https protocol, then in pure theory, the provenance and integrity of the file is established. But, in any case, all of that is really kind of an ersatz problem, isn't it?. The whole idea that somebody would put up with all the existing bugs in the legacy JavaCC, in the full knowledge that there is a version available where all these things are fixed, simply because the broken, obsolete version is on Maven Central....

      Anyway, on balance, I tend towards just maintaining the current policy regarding "versioning" because somehow, I don´t believe that getting into all this formalistic versioning stuff is really going to get us all kinds of new users. I could be wrong, I suppose, but that is my gut feeling.