adMartem
Well, "code too large" is really a pretty silly, trivial problem at root. As you surely understand, the problem is that a single Java method cannot compile into more than 64K bytecodes. And the way this is usually a problem is in terms of static initialization code. So if you have:
static private EnumSet<TokenType> Foo_FIRST_SET = EnumSet.of(A, B, C,...);
static private EnumSet<TokenType> Bar_FIRST_SET = EnumSet.of(D, E, F, ....);
.... 1000 more lines like this maybe...
All of these static initializations end up being compiled into a single static initialization method and that method, can easily end up being over 64K in bytecode.
But that is hardly such a big problem really. The general solution to the above is to break the initialization up into multiple methods none of which pass the 64K limit. So, for the above, you would need to generate something more like:
static private EnumSet<TokenType> Foo_FIRST_SET, Bar_FIRST_SET, BAZ_FIRST_SET, etc. etc. ;
So, you define the fields and then, assuming that initializing them in a single method hits the "code too large" issue, you need to have your initialization in multiple methods, like:
static void static_init1() {
Foo_FIRST_SET = EnumSet.of(A,B,C,....);
Bar_FIRST_SET = EnumSet.of(D,E,F,....);
and so on...
}
And then:
static void static_init2() {
the next group of initializations
}
...
static void static_init10() {
the final group of initializations
}
And then elsewhere:
static {
static_init1();
static_init2();
....
static_init10();
}
Well, in the above, there are 10 static initialization methods, but it could be something else. It's probably not too hard to do some rough calculations as to how many of them you actually do need and then generate them. So it's a question of mucking with the template to generate code more like the above. So, if you are comfortable editing FreeMarker templates, you could well have a go at it.
Or alternatively, I guess you could send me your grammar by private email and I'll see if I can get it working.
I really thought I had nailed the various "code too large" scenarios and then you came along and were still running into this. Well, I guess I declared victory prematurely, kind of like George Bush on that aircraft carrier. But regardless, we will have our clear victory over this. (Unlike George Bush...)
But, you know, the whole thing is such a testament to how stagnant some of these projects are. Generating code that doesn't compile because of "code too large" is major PITA in both legacy JavaCC and ANTLR. (Though actually I just googled a bit and it may be that this was a big problem in ANTLR3 and they refactored the code generation to avoid it in ANTLR4. Not sure...) But regardless, it is just amazing because it's a trivial problem and the ostensible project maintainers of JavaCC have never tamed this issue in 20 years or so!
Actually, their modus operandi is that any problem like this is just a "known issue" somehow and it is just accepted that they're never going to address it.
Oh well, as a veteran JavaCC user, you know all that, I guess! LOL.