About to rip out JAVACODE productions. Does anybody object to this?

You know, I bet there are some long-term users of JavaCC who aren't even aware that JavaCC has this thing called a JAVACODE production. (If you were unaware of this, you weren't missing much!)

Basically, the idea is that you can define something that is, to all intents and purposes, just a plain old java method (POJM?) but that is somehow treated as if it was a grammatical production.

The main purpose of it seems to be to support really horrible kludges. Actually, as best I can see, relatively few JavaCC grammars in the wild have any JAVACODE productions and I myself never wrote one, but when it is used, what you typically see is just something like:

JAVACODE void scan_to_matching_brace()
{
   Token tok = getToken(1);
   while (tok.kind != RBRACE) getNextToken();
}

Of course, this is not a grammatical production in any real sense. It's just a hack. Basically, when you enter code like this, you've gone completely off the rails and you're using some sort of extremely crude, bloody minded approach to try to get back on the rails -- in this case, scanning forward to the next closing brace and seeing whether you can trick your parsing machinery into carrying on from there. (Good luck with that!)

The thing is that I am trying to deal with these situations (fault-tolerant parsing, broadly speaking...) in a much more systematic way and having this JAVACODE production "feature" (using the word "feature" generously) is actually just in my way.

It's a funny thing because JAVACODE productions are actually like a big hole in the overall logical system, sort of like null in Java -- this big hole in the type system. It's actually quite amazing how much of the JavaCC code internally is based on handling the possibilities of JAVACODE productions, all this extra code for handling the screwy cases. So, basically, I think my intention is to do for JAVACODE productions in JavaCC. what Kotlin seems to have done for Java nulls, just ban them.

Well, I'm almost certainly going to do this, but I thought I'd just ask people whether this is something anybody objects to.

Oh, in other matters, I got rid of LexicalException a while ago. Now, all exceptions that the parser throws are ParseException. The way that works is that lexically invalid input creates a special kind of Token called InvalidInput and your parsing machinery doesn't know how to deal with it, of course, so it ends up throwing a ParseException just as it would with any other sort of unexpected Token type. I'm wondering whether this is a great discovery. Invalid input is actually a Token, just the same as zero is actually a number.

I didn't even ask anybody about this. I have been aware for some time that this distinction between ParseException and Lexical Exception was never worth the candle.

On getting rid of these JAVACODE productions, for some reason, I thought I should ask people. Would anybody miss them?