bnaudts Thanks, my tests are green again.
I really appreciate that you're following the latest Java language changes. I'd be out of my depth if I had to update Java.ccc myself.
Actually, I am pretty sure you would be able to do it. Maintaining Java.ccc is not a very hard part of this project. Really it isn't. Probably the most challenging work one has to do is on the templates side. In particular, keeping three sets of templates working for the three supported languages... just Java is hard enough, but having two more languages (that I don't know nearly as well) is another matter. And besides that, it's not like there are so many new language features usually. There is a new JDK every 6 months but sometimes there is no new language feature at all. Or typically just one or two things.
Of course, the problem is if you let things slide for a number of years, then catching up could be daunting. But as long as you don't allow yourself to get too far behind, simply keeping up with the current state of the language is not a very big time commitment.
This project has actually existed for a long time, since 2008 (it was called FreeCC originally) but was effectively abandonware from early 2009 to the end of 2019, just about 11 years. So when I picked it up again, there was over a decade of language evolution in Java to catch up on. In particular, the move from JDK 7 to 8 was quite revolutionary, since it introduced lambdas and so on. So I picked it up again at the very end of 2019 and the parser inside did not parse anything past JDK 5, I think. And it was not terribly correct even for JDK 5. There were holes. So I set myself the task of getting it up to JDK 8 level. I figured I'd get it to there initially and turn my attention to some other things and get back to it. The latest JDK was 13 at the time and maybe a month or two later I did get back to it and got the thing going up to the latest stable features in JDK 13. Since then, if there was a new JDK out with a new language feature or two, I'd put in a bit of time (not much really) to get it going again.
As for the why...
Five years ago I started to develop a Java static code analyzer focused on modification and immutability: e2immu (Effective and Eventual Immutability, www.e2immu.org. It's open source, but I don't think anyone knows it exists -- I'm not good at self-promotion.)
Yeah, I understand. I also am apparently not good at promoting my work. And the whole situation is pretty disheartening. I mean, what is the point of having some great thing if nobody knows about it?
I think one thing we should do is have something like a "powered by" page and a "testimonials page". Someone using this (YOU for example!) could write some "testimonial" saying how great this is and we could collect these and put it on a testimonials page. And a "powered by" page, that when it comes to our attention that somebody is using the tool, just to add it to the list. And maybe you could (in some appropriate point on your site) state that you are using this and provide a link to our project. So we should do at least such minimal things, no?
Two years ago I founded the for-profit company CodeLaser (www.codelaser.io) with an ex-colleague. We're writing tools to help modernize and refactor Java code, and the basis of the refactoring engine is the e2immu analyzer.
Last year I switched e2immu's core parser from JavaParser.org to CongoCC, partly because it'd allow us to add more languages in the future -- most of our stack is language agnostic, and it'd be really cool to add languages such as C#.
As far as I could ever tell, the main raison d'être of the JavaParser project is to provide a parser for the Java language. That is actually not the case for CongoCC. CongoCC provides grammars/parsers for Java, C# and Python, but it is actually incidental. Since we need those things internally, they are available for anybody else to use, but they are not the main goal of the project. Actually, I very much doubt that I have spent, let's say... 5% of my ongoing time in this project to maintaining the Java grammar. Probably even less, like 2 or 3%, but I'm not keeping track. So this JavaParser project, which is quite well known, famous.... has as its main goal to have a java parser (it's in the name) and has been around for quite a few years, while I, a single individual, maintain an up-to-date, correct Java parser just sort of incidentally, with just a tiny fraction of my ongoing time commitment to this application space!
I don't know if I say the above just to boast (okay, maybe a bit...) but there is a further point about all of this. I've eyeballed the JavaParser project a bit in the past. One notable aspect of it is that they have worked up some quite extensive Node API inside their project. You know, they build up the tree, and all the nodes of the tree implement the various interfaces or inherent from the abstract classes they have defined and so on... you know how it goes...
What I find noteworthy is that this entire API they have constructed (many many thousands of lines of code!) is (as far as I can tell) exclusively for use with their Java parser. CongoCC also maintains a similar (I suppose it's similar) Node API. Any CongoCC project generates the same Node API (though you can tweak it using INJECT and so on), all this stuff like node.descendantsOfType(MyNode.class) or the Node.Visitor and things like this. But this same Node API is automatically generated for any CongoCC parser -- for the ones that are there out-of-the-box, like Java, Python, and C#. Lua as well.... The day that we (or somebody else hopefully!) implements a parser for Typescript of PHP or whatever... it comes with the same Node API! It's just automatically there. The entire Node API that you would use with our Java parser is just generated, but with the help of a few injections, you have something that basically makes sense. But if you write a Typescript grammar, with a set of similar injections, you can generate a Node API that works for that language, so...
In fact, come to think of it, anybody who is already using CongoCC, could pretty easily just re-use the Node API for whatever purposes, like just subclass BaseNode maybe. Well, you see my point surely...
We hope to launch our 1.0 version at the Devoxx conference in October, which is why I'm going through an extensive testing phase at the moment -- hence the nitpicking over currently underused Java features.
Well, you do right to show up and "nitpick". If there is any other feature you feel could be useful, you can mention it certainly. How else would we know about it? No guarantees, of course...
If all goes well we'll be depending on CongoCC for many years to come. Given that we're promoting "modern Java code" we feel obliged to use the latest and greatest of Java ourselves, which is how I bumped into these record pattern issues while running our own code base through the analyzer.
Yeah, I understand. Eventually, this would come to our attention because one tries to run the parser over whatever codebase and eventually you hit a file or two that use this feature and then... But in the normal course of things that might not happen for a while, like a year maybe...