The Java parser skeletons are selected using the
directive or the -L java/--language=java option.
When generating a Java parser, ‘bison basename.y’ will create a
single Java source file named basename.java containing the
parser implementation. Using a grammar file without a .y suffix is
currently broken. The basename of the parser implementation file can be
changed by the
%file-prefix directive or the
-b/--file-prefix option. The entire parser implementation
file name can be changed by the
%output directive or the
-o/--output option. The parser implementation file
contains a single class for the parser.
You can create documentation for generated parsers using Javadoc.
Contrary to C parsers, Java parsers do not use global variables; the state
of the parser is always local to an instance of the parser class.
Therefore, all Java parsers are “pure”, and the
directive does nothing when used in Java.
Push parsers are currently unsupported in Java and
api.push-pull have no effect.
GLR parsers are currently unsupported in Java. Do not use the
No header file can be generated for Java parsers. Do not use the
%defines directive or the -d/--defines options.
Currently, support for tracing is always compiled
in. Thus the ‘%define parse.trace’ and ‘%token-table’
directives and the
-t/--debug and -k/--token-table
options have no effect. This may change in the future to eliminate
unused code in the generated parser, so use ‘%define parse.trace’
if needed. Also, in the future the
%token-table directive might enable a public interface to
access the token names and codes.
Getting a “code too large” error from the Java compiler means the code hit the 64KB bytecode per method limitation of the Java class file. Try reducing the amount of code in actions and static initializers; otherwise, report a bug so that the parser skeleton will be improved.