(The current Java interface is experimental and may evolve. More user feedback will help to stabilize it.)
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
directive or the -p/--name-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
%define api.pure directives do 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.