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.
GLR parsers are currently unsupported in Java. Do not use the
No header file can be generated for Java parsers. Do not use the
%header directive or the -d/-H/--header
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’ explicitly 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.