[antlr-interest] Antlr 3 generates very big java classes which do not compile

[gmx]

Thanks for your response

Actually That grammar served just as a (bad) example for one possible way to 
generate a case insensitive formal description of a grammar. I really know 
how to workaround the problem an that there are other, more efficient ways to 
achieve case insensitivity [at least I think so :-)].

However, my intention was just to mention the problem about the generated java 
code, which might get to big to comply with the java specification. At the 
moment I am writting my diploma about writting a parser for a very complex 
and featurerich proprietary programming language (PL/SQL). That language 
supports so many different kinds of statements and other constructs, that it 
is very likely that the generated parser will be to big to fit into one java 
class. (This is because java class files are limited to 65535 entries in 
their constant pool)

So the actual question is. Wether to create an additional java backend for 
antlr which will not only emit on source file (*.java) for the lexer and one 
for the parser, but will create several files so that these still comply to 
the java specification and can be compiled?
E.g. Instead of one java source file for the whole parse, a source file is 
created for each rule in the grammar.

Kind regards
Alex

Am Montag, 25. Dezember 2006 00:27 schrieb Kay Roepke:
> On 24. Dec 2006, at 19:16 , Terence Parr wrote:
> > Ok, I just have to ask: why do you do
> >
> > COLLECT : C O L L E C T;
> >
> > when you can do
> >
> > COLLECT : 'COLLECT';
>
> Seems the OP wanted to emulate case insensitivity by using
> fragment C : 'c'|'C';
> rules....
>
> cheers,
> -k