---

10.3.1 Java Bison Interface

The Java parser skeletons are selected using the %language "Java" 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 %define api.pure directive does nothing when used in Java.

GLR parsers are currently unsupported in Java. Do not use the glr-parser directive.

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