Giter Site home page Giter Site logo

javacc / javacc Goto Github PK

View Code? Open in Web Editor NEW
1.2K 40.0 247.0 6.68 MB

JavaCC - a parser generator for building parsers from grammars. It can generate code in Java, C++ and C#.

Home Page: https://javacc.org

License: BSD 3-Clause "New" or "Revised" License

Shell 0.59% Java 99.17% HTML 0.16% Batchfile 0.08%

javacc's Introduction

JavaCC

Maven Central Javadocs

Java Compiler Compiler (JavaCC) is the most popular parser generator for use with Java applications.

A parser generator is a tool that reads a grammar specification and converts it to a Java program that can recognize matches to the grammar.

In addition to the parser generator itself, JavaCC provides other standard capabilities related to parser generation such as tree building (via a tool called JJTree included with JavaCC), actions and debugging.

All you need to run a JavaCC parser, once generated, is a Java Runtime Environment (JRE).

This README is meant as a brief overview of the core features and how to set things up to get yourself started with JavaCC. For a fully detailed documentation, please see https://javacc.github.io/javacc/.

Contents

Introduction

Features

  • JavaCC generates top-down (recursive descent) parsers as opposed to bottom-up parsers generated by YACC-like tools. This allows the use of more general grammars, although left-recursion is disallowed. Top-down parsers have a number of other advantages (besides more general grammars) such as being easier to debug, having the ability to parse to any non-terminal in the grammar, and also having the ability to pass values (attributes) both up and down the parse tree during parsing.

  • By default, JavaCC generates an LL(1) parser. However, there may be portions of grammar that are not LL(1). JavaCC offers the capabilities of syntactic and semantic lookahead to resolve shift-shift ambiguities locally at these points. For example, the parser is LL(k) only at such points, but remains LL(1) everywhere else for better performance. Shift-reduce and reduce-reduce conflicts are not an issue for top-down parsers.

  • JavaCC generates parsers that are 100% pure Java, so there is no runtime dependency on JavaCC and no special porting effort required to run on different machine platforms.

  • JavaCC allows extended BNF specifications - such as (A)*, (A)+ etc - within the lexical and the grammar specifications. Extended BNF relieves the need for left-recursion to some extent. In fact, extended BNF is often easier to read as in A ::= y(x)* versus A ::= Ax|y.

  • The lexical specifications (such as regular expressions, strings) and the grammar specifications (the BNF) are both written together in the same file. It makes grammars easier to read since it is possible to use regular expressions inline in the grammar specification, and also easier to maintain.

  • The lexical analyzer of JavaCC can handle full Unicode input, and lexical specifications may also include any Unicode character. This facilitates descriptions of language elements such as Java identifiers that allow certain Unicode characters (that are not ASCII), but not others.

  • JavaCC offers Lex-like lexical state and lexical action capabilities. Specific aspects in JavaCC that are superior to other tools are the first class status it offers concepts such as TOKEN, MORE, SKIP and state changes. This allows cleaner specifications as well as better error and warning messages from JavaCC.

  • Tokens that are defined as special tokens in the lexical specification are ignored during parsing, but these tokens are available for processing by the tools. A useful application of this is in the processing of comments.

  • Lexical specifications can define tokens not to be case-sensitive either at the global level for the entire lexical specification, or on an individual lexical specification basis.

  • JavaCC comes with JJTree, an extremely powerful tree building pre-processor.

  • JavaCC also includes JJDoc, a tool that converts grammar files to documentation files, optionally in HTML.

  • JavaCC offers many options to customize its behavior and the behavior of the generated parsers. Examples of such options are the kinds of Unicode processing to perform on the input stream, the number of tokens of ambiguity checking to perform etc.

  • JavaCC error reporting is among the best in parser generators. JavaCC generated parsers are able to clearly point out the location of parse errors with complete diagnostic information.

  • Using options DEBUG_PARSER, DEBUG_LOOKAHEAD, and DEBUG_TOKEN_MANAGER, users can get in-depth analysis of the parsing and the token processing steps.

  • The JavaCC release includes a wide range of examples including Java and HTML grammars. The examples, along with their documentation, are a great way to get acquainted with JavaCC.

An example

The following JavaCC grammar example recognizes matching braces followed by zero or more line terminators and then an end of file.

Examples of legal strings in this grammar are:

{}, {% raw %}{{{{{}}}}}{% endraw %} // ... etc

Examples of illegal strings are:

{}{}, }{}}, { }, {x} // ... etc

Its grammar
PARSER_BEGIN(Example)

/** Simple brace matcher. */
public class Example {

  /** Main entry point. */
  public static void main(String args[]) throws ParseException {
    Example parser = new Example(System.in);
    parser.Input();
  }

}

PARSER_END(Example)

/** Root production. */
void Input() :
{}
{
  MatchedBraces() ("\n"|"\r")* <EOF>
}

/** Brace matching production. */
void MatchedBraces() :
{}
{
  "{" [ MatchedBraces() ] "}"
}
Some executions and outputs
{{}} gives no error
$ java Example
{{}}<return>
{x gives a Lexical error
$ java Example
{x<return>
Lexical error at line 1, column 2.  Encountered: "x"
TokenMgrError: Lexical error at line 1, column 2.  Encountered: "x" (120), after : ""
        at ExampleTokenManager.getNextToken(ExampleTokenManager.java:146)
        at Example.getToken(Example.java:140)
        at Example.MatchedBraces(Example.java:51)
        at Example.Input(Example.java:10)
        at Example.main(Example.java:6)
{}} gives a ParseException
$ java Example
{}}<return>
ParseException: Encountered "}" at line 1, column 3.
Was expecting one of:
    <EOF>
    "\n" ...
    "\r" ...
        at Example.generateParseException(Example.java:184)
        at Example.jj_consume_token(Example.java:126)
        at Example.Input(Example.java:32)
        at Example.main(Example.java:6)

Getting Started

You can use JavaCC either from the command line or through an IDE.

Use JavaCC from the command line

Download

Download the latest stable release (at least the source and the binaries) in a so called download directory:

All JavaCC releases are available via GitHub and Maven including checksums and cryptographic signatures.

For all previous releases, please see stable releases.

Install

Once you have downloaded the files, navigate to the download directory and unzip the source file, this creating a so called JavaCC installation directory:

$ unzip javacc-7.0.13.zip
or
$ tar xvf javacc-7.0.13.tar.gz

Then move the binary file javacc-7.0.13.jar under the download directory in a new target/ directory under the installation directory, and rename it to javacc.jar.

Then add the scripts/ directory in the JavaCC installation directory to your PATH. The JavaCC, JJTree, and JJDoc invocation scripts/executables reside in this directory.

On UNIX based systems, the scripts may not be executable immediately. This can be solved by using the command from the javacc-7.0.13/ directory:

chmod +x scripts/javacc

Write your grammar and generate your parser

You can then create and edit a grammar file with your favorite text editor.

Then use the appropriate script for generating your parser from your grammar.

Use JavaCC within an IDE

Minimal requirements for an IDE are:

  • Support for Java
  • Support for Maven with Java

IntelliJ IDEA

The IntelliJ IDE supports Maven out of the box and offers a plugin for JavaCC development.

Eclipse IDE

Maven

Add the following dependency to your pom.xml file.

<dependency>
    <groupId>net.java.dev.javacc</groupId>
    <artifactId>javacc</artifactId>
    <version>7.0.13</version>
</dependency>

Gradle

Add the following to your build.gradle file.

repositories {
    mavenLocal()
    maven {
        url = 'https://mvnrepository.com/artifact/net.java.dev.javacc/javacc'
    }
}

dependencies {
    compile group: 'net.java.dev.javacc', name: 'javacc', version: '7.0.13'
}

Rebuilding JavaCC

From the source installation directory

The source installation directory contains the JavaCC, JJTree and JJDoc sources, launcher scripts, example grammars and documentation, and also a bootstrap version of JavaCC needed to build JavaCC.

Prerequisites for building JavaCC with this method:

  • Ant (we require version 1.5.3 or above - you can get ant from http://ant.apache.org)
  • Maven
  • Java 8 (Java 9 and 10 are not yet supported)

Use the ant build script:

$ cd javacc
$ ant

This will build the javacc.jar file in the target/ directory

After cloning the JavaCC GitHub repository

This is the preferred method for contributing to JavaCC.

Prerequisites for building JavaCC with this method:

  • Git
  • Ant (we require version 1.5.3 or above - you can get ant from http://ant.apache.org)
  • Maven
  • Java 8 (Java 9 and 10 are not yet supported)

Just clone the repository and then use the ant build script:

$ git clone https://github.com/javacc/javacc.git
$ cd javacc
$ ant

This will build the javacc.jar file in the target/ directory

Community

JavaCC is by far the most popular parser generator used with Java applications with an estimated user base of over 1,000 users and more than 100,000 downloads to date.

It is maintained by the developer community which includes the original authors and Chris Ainsley, Tim Pizney and Francis Andre.

Support

Don’t hesitate to ask!

Contact the developers and community on the Google user group or email us at JavaCC Support if you need any help.

Open an issue if you found a bug in JavaCC.

For questions relating to development please join our Slack channel.

Documentation

The documentation of JavaCC is located on the website https://javacc.github.io/javacc/ and in the docs/ directory of the source code on GitHub.

It includes detailed documentation for JavaCC, JJTree, and JJDoc.

Resources

Books
  • Dos Reis, Anthony J., Compiler Construction Using Java, JavaCC, and Yacc., Wiley-Blackwell 2012. ISBN 0-4709495-9-7 (book, pdf).
  • Copeland, Tom, Generating Parsers with JavaCC., Centennial Books, 2007. ISBN 0-9762214-3-8 (book).
Tutorials
Articles
Parsing theory
  • Alfred V. Aho, Monica S. Lam, Ravi Sethi and Jeffrey D. Ullman, Compilers: Principles, Techniques, and Tools, 2nd Edition, Addison-Wesley, 2006, ISBN 0-3211314-3-6 (book, pdf).
  • Charles N. Fischer and Richard J. Leblanc, Jr., Crafting a Compiler with C., Pearson, 1991. ISBN 0-8053216-6-7 (book).

Powered by JavaCC

JavaCC is used in many commercial applications and open source projects.

The following list highlights a few notable JavaCC projects that run interesting use cases in production, with links to the relevant grammar specifications.

User Use Case Grammar File(s)
Apache ActiveMQ Parsing JMS selector statements SelectorParser.jj, HyphenatedParser.jj
Apache Avro Parsing higher-level languages into Avro Schema idl.jj
Apache Calcite Parsing SQL statements Parser.jj
Apache Camel Parsing stored SQL templates sspt.jj
Apache Jena Parsing queries written in SPARQL, ARQ, SSE, Turtle and JSON sparql_10, sparql_11, arq.jj, sse.jj, turtle.jj, json.jj
Apache Lucene Parsing search queries QueryParser.jj
Apache Tomcat Parsing Expression Language (EL) and JSON ELParser.jjt, JSONParser.jj
Apache Zookeeper Optimising serialisation/deserialisation of Hadoop I/O records rcc.jj
Java Parser Parsing Java language files java.jj

License

JavaCC is an open source project released under the BSD License 2.0. The JavaCC project was originally developed at Sun Microsystems Inc. by Sreeni Viswanadha and Sriram Sankar.



Top


javacc's People

Contributors

albert-github avatar alphahinex avatar black-photon avatar blama avatar don-vip avatar emspishak avatar fandremxw avatar grimreaper avatar inponomarev avatar jbdamiano avatar kasumigaokautaha avatar leventov avatar marcmazas avatar martinswanson avatar mbrigl avatar mernst avatar moonfruit avatar new-javacc avatar phax avatar raipc avatar rhwood avatar risavk avatar schorrm avatar simon04 avatar tsmock avatar vlsi avatar wuare avatar yoshijava avatar zbynek avatar zosrothko avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

javacc's Issues

Cannot change JAVA_TEMPLATE_TYPE

When I pass -JAVA_TEMPLATE_TYPE:modern on the command line, I still get the legacy Error throws in the generated output code. I've been reading through the Options code and it looks like NONUSER_OPTION__LEGACY_EXCEPTION_HANDLING is set in init when it's called in Main before the parsing of command line options.

I don't care about GWT at all - as has been mentioned before, I'm really after the cleaner generated code because the Java compiler likes to complain about unreachable code. I can hard code some suppression in annotations in the jj file but that's an ugly hack when this option exists.

javacc.org is out of date

The javacc.org site still promotes javacc 6.
While searching for why this would be the case, I found out that there's a javacc 8 in development. Is this stable for use?

Is there a possibility to switch off tokens via options?

I have the need to build a parser for two different language versions. I want to avoid to build two parsers and have two grammar files. Using semantic Lookahead one is able to switch production on/off. The same would be nice for tokens.

I tried token modes, but in reality, I have multiple options/flags that could be combined. Therefore this is not a valid way.

As mentioned I would like to skip to build a parser for each of my options combinations.

cannot find symbol JavaCharStream.staticFlag

A parser generated with 7.0.4 doesn't compile because it cannot find JavaCharStream.staticFlag.

These are my parser options:

options 
{
	STATIC=false;
	JAVA_UNICODE_ESCAPE=true;
}

I get these compilation errors:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project blacklab: Compilation failure: Compilation failure:
[ERROR] /home/jan/projects/blacklab/core/src/main/java/nl/inl/blacklab/queryParser/contextql/GeneratedContextualQueryLanguageParserTokenManager.java:[609,25] cannot find symbol
[ERROR] symbol:   variable staticFlag
[ERROR] location: class nl.inl.blacklab.queryParser.contextql.JavaCharStream
[ERROR] /home/jan/projects/blacklab/core/src/main/java/nl/inl/blacklab/queryParser/contextql/GeneratedContextualQueryLanguageParserTokenManager.java:[609,10] illegal start of type

This is the code referred to:

/** Constructor. */
public GeneratedContextualQueryLanguageParserTokenManager(JavaCharStream stream){
  if (JavaCharStream.staticFlag)
    throw new RuntimeException("ERROR: Cannot use a static CharStream class with a non-static lexical analyzer.");
  input_stream = stream;
}

The generated JavaCharStream class doesn't have a staticFlag variable, hence the error.

If I comment out the if statement, it seems to work.

javaCC inserts non-wanted statements

cross posted at http://stackoverflow.com/questions/43469509/

I've got the following javacc grammar.

The rule UnaryExpr creates some anonymous classes implementing java.util.function.Predicate<>

options {
static=false;
DEBUG_PARSER=false;
IGNORE_CASE=true;
JDK_VERSION="1.8";
}

(...)

private Predicate<SAMRecord> UnaryExpr(): { }
    {
    (
    <DUPLICATE> { return new Predicate<SAMRecord>() {
            @Override public boolean test(final SAMRecord rec) { return rec.getDuplicateReadFlag();}
        };}
    | <UNMAPPED> { return new Predicate<SAMRecord>() {
            @Override public  boolean test(final SAMRecord rec) { return rec.getReadUnmappedFlag();}
        };}
    | <FAILSVENDORQUALITY> { return new Predicate<SAMRecord>() {
            @Override public  boolean test(final SAMRecord rec) { return rec.getReadFailsVendorQualityCheckFlag();}
        };}
    | <PROPERPAIR> { return new Predicate<SAMRecord>() {
            @Override public boolean test(final SAMRecord rec) { return rec.getReadPairedFlag();}
        };}
    )
    }

when I'm generating the code using javacc 7.0.2, the generated java code contains some extra statements that break the code {if ("" != null). In the java file, instead or my original code:

@Override public boolean test(final SAMRecord rec) {return rec.getDuplicateReadFlag();}

I get :

@Override public boolean test(final SAMRecord rec) { {if ("" != null) return rec.getDuplicateReadFlag();}}

How can I fix this ? Thanks .

PS: I've also tried to use java 8 lambda, but the java parser doesn't handle the following code: <UNMAPPED> { return rec->rec.getReadUnmappedFlag();}

LOOKAHEAD in ExpansionUnit never reached

Hi all

The JavaCC grammar file description states:
expansion ::= ( expansion_unit )* // by the way it is +, not *
expansion_unit ::= local_lookahead | java_block | ...

But the JavaCC.jj file states (in the same notation):
expansion ::= ( local_lookahead )? ( expansion_unit )+ // referred LLE
expansion_unit ::= local_lookahead | java_block | ... // referred LLEU

But by tracing, code coverage... on different examples, it looks to me that the LLEU is never matched.
The corresponding warnings ("Encountered LOOKAHEAD(...) at a non-choice location. Only semantic lookahead will be considered here." and "Encountered LOOKAHEAD(...) at a non-choice location. This will be ignored.") are produced by Semanticize.LookaheadFixer(), not by JavaCCParser.expansion_unit(...).

Am I wrong? If yes, can one give me a grammar example showing the LLEU case ?
TIA. Marc

Strange tokenImage

The grammar listed below generates in the xxConstants.java file a strange tokenImage value for some regular expressions.
Entries 10 & 11 should be, IMHO, "<FORMAL_COMMENT>" and "<MULTI_LINE_COMMENT>" instead of ""*/"" for both (like entry 9 "<SINGLE_LINE_COMMENT>").

Generated Constants file :
/* Generated By:JavaCC: Do not edit this line. ElementsUsuels2Constants.java */
package tp2;

/**

  • Token literal values and constants.
  • Generated by org.javacc.parser.OtherFilesGen#start()
    */
    public interface ElementsUsuels2Constants {

/** End of File. /
int EOF = 0;
/
* RegularExpression Id. /
int LINE_COMMENT = 5;
/
* RegularExpression Id. /
int SINGLE_LINE_COMMENT = 9;
/
* RegularExpression Id. /
int FORMAL_COMMENT = 10;
/
* RegularExpression Id. /
int MULTI_LINE_COMMENT = 11;
/
* RegularExpression Id. /
int LETTER = 13;
/
* RegularExpression Id. /
int DIGIT = 14;
/
* RegularExpression Id. /
int NUM = 15;
/
* RegularExpression Id. /
int CHARACTER_LITERAL = 16;
/
* RegularExpression Id. /
int STRING_LITERAL = 17;
/
* RegularExpression Id. */
int ID = 18;

/** Lexical state. /
int DEFAULT = 0;
/
* Lexical state. /
int IN_SINGLE_LINE_COMMENT = 1;
/
* Lexical state. /
int IN_FORMAL_COMMENT = 2;
/
* Lexical state. */
int IN_MULTI_LINE_COMMENT = 3;

/** Literal token values. /
String[] tokenImage = {
"",
"" "",
""\t"",
""\n"",
""\r"",
"<LINE_COMMENT>",
""//"",
"<token of kind 7>",
""/
"",
"<SINGLE_LINE_COMMENT>",
""/"",
""
/"",
"<token of kind 12>",
"",
"",
"",
"<CHARACTER_LITERAL>",
"<STRING_LITERAL>",
"",
};

}

Grammar :
PARSER_BEGIN(ElementsUsuels2)
package tp2;

/** Une illustration de "regular_expr_production" fréquemment rencontrées. */
public class ElementsUsuels2
{
public static final void main(String args []) throws ParseException
{
ElementsUsuels2 parser = new ElementsUsuels2(System.in);
parser.ProgramUnit();
}

static void dump(Token aT) {
System.out.print("Token type = " + tokenImage[aT.kind] + ", image = " + aT.image);
System.out.print(", bl = " + aT.beginLine + ", bc = " + aT.beginColumn);
System.out.print(", el = " + aT.endLine + ", ec = " + aT.endLine + ", special = (<");
Token st = aT.specialToken;
while (st != null && st.specialToken!= null) {
st = st.specialToken;
}
while (st != null) {
System.out.print(tokenImage[st.kind] + ">/<" + st.image + ">)(<");
st = st.next;
}
System.out.println(">)");
}
}

PARSER_END(ElementsUsuels2)

SKIP :
{
" "
| "\t"
| "\n"
| "\r"
}

SPECIAL_TOKEN :
{
< LINE_COMMENT : "--" (~[ "\r", "\n" ])* >
}

MORE :
{
"//" : IN_SINGLE_LINE_COMMENT
|
< "/**" ~[ "/" ] >
{
input_stream.backup(1);
}
: IN_FORMAL_COMMENT
|
"/*" : IN_MULTI_LINE_COMMENT
}

< IN_SINGLE_LINE_COMMENT >
SPECIAL_TOKEN :
{
< SINGLE_LINE_COMMENT :
"\n"
| "\r"
| "\r\n" > : DEFAULT
}

< IN_FORMAL_COMMENT >
SPECIAL_TOKEN :
{
< FORMAL_COMMENT : "*/" > : DEFAULT
}

< IN_MULTI_LINE_COMMENT >
SPECIAL_TOKEN :
{
< MULTI_LINE_COMMENT : "*/" > : DEFAULT
}

< IN_SINGLE_LINE_COMMENT, IN_FORMAL_COMMENT, IN_MULTI_LINE_COMMENT >
MORE :
{
< ~[ ] >
}

TOKEN :
{
< #LETTER : [ "a"-"z", "A"-"Z", "_" ] >
|
< #DIGIT : [ "0"-"9" ] >
|
< NUM : (< DIGIT >)+ >
|
< CHARACTER_LITERAL :
"'"
(
(~[ "'", "\", "\n", "\r" ])
|
(
"\"
(
[ "n", "t", "b", "r", "f", "\", "'", """ ]
| [ "0"-"7" ] ([ "0"-"7" ])?
| [ "0"-"3" ] [ "0"-"7" ] [ "0"-"7" ]
)
)
)
"'"

|
< STRING_LITERAL :
"""
(
(~[ """, "\", "\n", "\r" ])
|
(
"\"
(
[ "n", "t", "b", "r", "f", "\", "'", """ ]
| [ "0"-"7" ] ([ "0"-"7" ])?
| [ "0"-"3" ] [ "0"-"7" ] [ "0"-"7" ]
)
)
)*
"""

|
< ID :
< LETTER >
(
< LETTER >
| < NUM >
)* >
}

void ProgramUnit() :
{
Token t;
}
{
(
(
t = < ID >
| t = < NUM >
| t = < CHARACTER_LITERAL >
| t = < STRING_LITERAL >
)
{
dump(t);
}
)+
< EOF >
}

Branches/Tages to differentiate versions

I noticed that the git repository doesn't have branches or tags to specify the respective versions.

Can you please start using tags/branches so we exactly what version we are using?

Thanks

Is there any way to generate non-final methods for rule?

For example, for a rule expression a method final public Expression Expression() throws ParseException is generated. I would need to have it not final because I am overrideing some methods later for a special parser which is template-aware

automatic connection between ast node and created production object

Imagine you have a production like

TestObject myProduction #testobjectnode {} : {
      {
            return new TestObject();
      }
}

If I want to connect both objects (TestObject, testobjectnode ) I have to use some special code like

setNode(jjtThis);

or so.

Could this be achieved automatically? Or is this even possible right now?

[New feature] Generic visitor generation

Hi,

I'm from the dev team of pmd, where we use javacc to generate ASTs for several languages. AST visitors are pervasive in our codebase, and we'd like to take steps to make them more typesafe and rely less on Object. We've been discussing this at pmd/pmd#880 but I'll synthesize everything here

Feature

We'd like javacc to be able to generate generic visitors, that is, a visitor such as this one

public interface JavaParserVisitor<T>
{
  public T visit(JavaNode node, T data);
  public T visit(ASTCompilationUnit node, T data);
  public T visit(ASTPackageDeclaration node, T data);
  // ...
}

The nodes' jjtAccept methods would then look like so:

public <T> T jjtAccept(JavaParserVisitor<T> visitor, T data)

Use case

This would for instance allow us to implement the interface like so:

public class NodeCounterVisitor implements JavaParserVisitor<MutableInt> {
  public MutableInt visit(JavaNode node, MutableInt data) {
    data.increment();  // we'd need a cast here without the type param
    return node.childrenAccept(this, data); // make children accept the visitor with same data instance. Returns data
  }
}

Which would allow us to count the descendants of a node using

int count = node.jjtAccept(new NodeCounterVisitor(), new MutableInt(0)).getValue();

without casts. That example is really contrived, but there are links to real examples in pmd/pmd#880, where the number of visit methods is high, and casts really reduce readability.

Implementation

I'm thinking about adding a new option to JJTree, something like "VISITOR_TYPE_PARAMS", with the following legal values for now:

  • "" (default) : the visitor is identical to what it is now
  • "uniform" : the interface declares one type parameter, the visit method signatures are like the following:
public T visit(JavaNode node, T data);

Uniform means that the same type param is used for argument type and return type. We could indeed imagine visitor interfaces with several type parameters (eg public R visit(JavaNode node, T data);), but I don't think we would have a use case for that so let's keep it simple for this feature

That is early thinking and maybe you have a better idea. Waiting for your comments ;)

Open questions

  • Are you interested in this feature and would agree to merge it should we implement it?
  • What are your requirements for contributing to javacc?
  • Should we add the possibility to generate several visitors side-by-side (eg one generic, another not generic)? With only two possible option values like what I describe here, we can very well replace the previous interface with the generic one. Implementing the raw type would be the same as implementing the previous, non-generic interface. But if we add more generic visitor flavours in the future, then we might need to generate those side-by-side, and with different names

Documenting generated code

I cannot find any documentation on the generated code, for example on the methods of the TokenManager.

Am I missing it or such documentation does not exist?

minimumSize=1 generated for choice that contains child with zero size

Following code lines seem to cause lookahead problems:

for (int i = 0; min > 1 && i < e_nrw.getChoices().size(); i++) {
nested_e = (Expansion)(e_nrw.getChoices().get(i));
int min1 = minimumSize(nested_e, min);
if (min > min1) min = min1;
}

The minimum consumed size will be limited to at least 1 for a choice. As a result sometimes the lookahead is finished too early. E.g. consider an production:

Syntax() -> {
  (
  LOOKAHEAD(2) 
  (<FOO> | {}) <BAR> <DUMMY>
  |
  <BAR> <BAR>
  )
}

If the input tokens is <BAR> <BAR>, apparently we should choose <BAR> <BAR> because of the lookahead for the former expansion is specified to 2. But with the code logic pasted above, the expansion [<FOO>] <BAR> will consume all the 2 lookahead count so that the generated parser code will never consider the token <DUMMY>. After all the former expansion will be chosen incorrectly. :(

To me it is definitely like a bug so I have opened a PR #87. If it is something by design (which means we should always use lookahead=3 in the case) please let me know.

javacc requires itself to build, bootstrap issue

It seems javacc is using its own solution to build itself. This is not really ideal as it creates a chicken and egg situation requiring use of a pre-built binary. Ideally there should be a clean solution to build from source. This maybe possible going back to an older version and chaining up from there. I have no problem with javacc using javacc for non-core aspects. But the initial build should not require javacc ,and then you can run what you just built to process any *.javacc files. Thank you for consideration of this request.

7.0.x dev : Breaking change discussion: Wish to change the default JAVA_TEMPLATE_TYPE = "modern";

A few years ago, as part of the 6.1.0 release I added a new code generation target, which was a subtarget of the Java code generation, primarily for GWT compatibility, but also to improve exception handling. I added an option called "JAVA_TEMPLATE_TYPE", leaving existing behaviour in tact under the banner of JAVA_TEMPLATE_TYPE = "classic" (which was the default).

In order to get the new code generation patterns, you would require to opt-in, which made it safe for a point release. I wish to make the "modern" pattern the new default.

Modern mode primarily performs 3 functions:

a) Internal interface based IO / GWT Compatibility
b) Better Exception Handling
c) Some additional boilerplate / helper methods

NOTE : No Unicode changes are present under this particular configuration option.

The classic (pre-modern) Java code generation emits many instances of code that throw java.lang.Error, which are typically unhandled.

JavaCharStream.template (already in 6.1.x / 7.0.x dev)

    catch (${LEGACY_EXCEPTION_HANDLING?Throwable:Exception} t)
    {
      throw new ${LEGACY_EXCEPTION_HANDLING?Error:RuntimeException}(t.getMessage());
    }

(where legacy exception handling is an internal property that is set when modern mode is specified)

It throws these Errors when encountering something it doesn't expect in the char stream, and for other reasons too.

This means that anyone using JavaCC generated Java based parsers has to catch 'java.lang.Throwable', which is generally frowned upon. In fact, this one aspect of JavaCC is the most dangerous.

It was always my intent to campaign for modern to become the new default, after a long enough incubation period.

Options.java (already in 6.1.x / 7.0.x dev)

/**
	 * 2013/07/22 -- GWT Compliant Output -- no external dependencies on GWT,
	 * but generated code adds loose coupling to IO, for 6.1 release, this is
	 * opt-in, moving forward to 7.0, after thorough testing, this will likely
	 * become the default option with classic being deprecated
	 */
	public static final String JAVA_TEMPLATE_TYPE_MODERN = "modern";

The GWT compliant code is also extremely useful with no drawbacks as far as I am aware.

The change I am proposing is simply this

Options.java (prior to change)

temp.add(new OptionInfo(USEROPTION__JAVA_TEMPLATE_TYPE, OptionType.STRING, JAVA_TEMPLATE_TYPE_CLASSIC));

Options.java (after change)

temp.add(new OptionInfo(USEROPTION__JAVA_TEMPLATE_TYPE, OptionType.STRING, JAVA_TEMPLATE_TYPE_MODERN));

As 7.0.0 is somewhat of a fresh start, I would like to see this become the default going forward. Discussion welcome.

JavaCC 8.0.0: NPE at org.javacc.cpp.todo.NfaState.DumpMoveNfa(NfaState.java:2818)

Hi

With latest JavaCC 8.0.0, one got

Z:\git\asn1cpp\code\ASN1Parser>java -cp z:\git\javacc-8.0\target\javacc.jar javacc
Java Compiler Compiler Version 8.0.0 (Parser Generator)

Z:\git\asn1cpp\code\ASN1Parser>java -cp z:\git\javacc-8.0\target\javacc.jar;Z:\git\javacc-8.0\codegenerator\cpp\cpp-codegenerator.jar javacc -output_directory=gen Parser.jj
Java Compiler Compiler Version 8.0.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file Parser.jj . . .
Warning: Output directory "gen" does not exist. Creating the directory.
Exception in thread "main" java.lang.NullPointerException
        at org.javacc.cpp.todo.NfaState.DumpMoveNfa(NfaState.java:2818)
        at org.javacc.cpp.TokenManagerCodeGenerator.generateCode(TokenManagerCodeGenerator.java:260)
        at org.javacc.parser.LexGen.start(LexGen.java:608)
        at org.javacc.parser.Main.mainProgram(Main.java:266)
        at org.javacc.parser.Main.main(Main.java:153)
        at javacc.main(javacc.java:36)

Characters handling issues

In a grammar file, in a java block, if you declare : char e = 'é';, you get an error:

in JavaCC 7.0 : org.javacc.parser.ParseException: Encountered " <ACT_TOK> "' "" at line 85, column 9.

in JavaCC 5.0 : Exception in thread "main" org.javacc.parser.TokenMgrError: Lexical error at line 85, column 11. Encountered: "\u00a9" (169), after : "'\u00c3"

escaping generates faulty code

Dear all,

I have this:

| <VALUE: ( ~[",",")","|"] )* ~["\\",",",")","|"] >

which results in this:

private int jjMoveStringLiteralDfa0_2(){
   switch(curChar)
   {
      case ')':
         return jjStopAtPos(0, 7);
      case ',':
         return jjStopAtPos(0, 9);
      case '\':
         return jjMoveStringLiteralDfa1_2(0x1000L);
      case '|':
         return jjStopAtPos(0, 11);
      default :
         return jjMoveNfa_2(2, 0);
   }
}

Am I doing something wrong? This works with maven plugin 2.6 / javacc 5 and 6.

perhaps this issue is for ph-javacc-maven-plugin 4.0.3.

Bye

javacc-8.0.0: IOException: Invalid template name: /templates/cpp/TokenManagerBoilerPlateMethods.template

HI

Testing the new javacc-8.0.0 code generator for c++

FrancisANDRE@DESKTOP-GU149JI /cygdrive/z/git/javacc-8.0/examples/JavaGrammars/cpp
$ make
java -cp ../../../target/javacc.jar jjtree  Java1.1.jjt
Java Compiler Compiler Version 8.0.0 (Tree Builder)
(type "jjtree" with no arguments for help)
Warning: VISITOR_RETURN_TYPE option will be ignored since VISITOR is false
Reading from file Java1.1.jjt . . .
Warning: Output directory "gen" does not exist. Creating the directory.
File "Node.h" does not exist.  Will create one.
File "JavaParserTree.h" does not exist.  Will create one.
File "JavaParserTree.cc" does not exist.  Will create one.
File "JavaParserTreeConstants.h" does not exist.  Will create one.
File "JJTJavaParserState.h" does not exist.  Will create one.
File "JJTJavaParserState.cc" does not exist.  Will create one.
Annotated grammar generated successfully in gen\Java1.1.jj
java -cp ../../../target/javacc.jar javacc  gen/Java1.1.jj
Java Compiler Compiler Version 8.0.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file gen/Java1.1.jj . . .
Exception in thread "main" java.io.IOException: Invalid template name: /templates/cpp/TokenManagerBoilerPlateMethods.template
       at org.javacc.utils.OutputFileGenerator.generate(OutputFileGenerator.java:79)
       at org.javacc.parser.LexGen.writeTemplate(LexGen.java:147)
       at org.javacc.parser.LexGenCPP.start(LexGenCPP.java:505)
       at org.javacc.parser.Main.mainProgram(Main.java:295)
       at org.javacc.parser.Main.main(Main.java:153)
       at javacc.main(javacc.java:36)
make: *** [Makefile:13: gen/*.cc] Error 1

Generation bug with javacode production

Hi
Here is a Ok.jj file that produces a java file with no compile error and a small modification in Ko.jj that produces a java file with a compile error.
The while loop in a() seems missing some code and does not return; also the jj_la1 is an int[0] instead of int[1].
These grammars have been stripped down to the simplest from real useful grammars.
Marc
Ko.jj.txt
Ok.jj.txt

No helper scripts under bin/

After unzipping https://javacc.org/downloads/javacc-6.0.zip , there's no help scripts like javacc, jjdoc, jjtree as mentioned on https://javacc.org/getting-started

unzip -l javacc-6.0.zip 
Archive:  javacc-6.0.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  03-07-2014 20:45   javacc-6.0/
        0  03-07-2014 20:45   javacc-6.0/bin/
        0  03-07-2014 20:45   javacc-6.0/bin/lib/
   386079  03-07-2014 20:45   javacc-6.0/bin/lib/javacc.jar
        0  03-07-2014 20:45   javacc-6.0/doc/
    10537  02-23-2011 14:49   javacc-6.0/doc/CharStream.html
     3837  02-23-2011 14:49   javacc-6.0/doc/JJDoc.html
    24195  02-23-2011 14:49   javacc-6.0/doc/JJTree.html
    69621  08-04-2013 21:46   javacc-6.0/doc/JavaCC.html
    28026  08-04-2013 21:46   javacc-6.0/doc/JavaCC.txt
    22347  07-06-2013 10:04   javacc-6.0/doc/apiroutines.html
     4747  02-23-2011 14:49   javacc-6.0/doc/commandline.html
     4782  02-23-2011 14:49   javacc-6.0/doc/docindex.html
    10661  02-23-2011 14:49   javacc-6.0/doc/errorrecovery.html
     7095  02-23-2011 14:42   javacc-6.0/doc/features.html
     4862  02-23-2011 14:49   javacc-6.0/doc/index.html
     3325  02-23-2011 14:49   javacc-6.0/doc/installhelp.html
     4783  07-06-2013 10:04   javacc-6.0/doc/javacc-c++-releasenotes.html
    57405  02-23-2011 14:49   javacc-6.0/doc/javaccgrm.html
    29320  07-06-2013 10:04   javacc-6.0/doc/javaccreleasenotes.html
     5220  02-23-2011 14:49   javacc-6.0/doc/jjdocreleasenotes.html
     2776  07-06-2013 10:44   javacc-6.0/doc/jjtree-c++-releasenotes.html
     6912  02-23-2011 14:49   javacc-6.0/doc/jjtreeREADME.html
    20243  02-23-2011 14:49   javacc-6.0/doc/jjtreeintro.html
    18355  07-06-2013 10:04   javacc-6.0/doc/jjtreereleasenotes.html
     5445  02-23-2011 14:49   javacc-6.0/doc/lexertips.html
    28634  02-23-2011 14:49   javacc-6.0/doc/lookahead.html
     2591  02-23-2011 14:49   javacc-6.0/doc/mailinglist.html
    17019  02-23-2011 14:49   javacc-6.0/doc/simpleREADME.html
     2134  02-23-2011 14:49   javacc-6.0/doc/support.html
    13328  02-23-2011 14:49   javacc-6.0/doc/tokenmanager.html
        0  03-07-2014 20:45   javacc-6.0/examples/
        0  03-07-2014 20:45   javacc-6.0/examples/CORBA-IDL/
        0  03-07-2014 20:45   javacc-6.0/examples/GUIParsing/
        0  03-07-2014 20:45   javacc-6.0/examples/GUIParsing/ParserVersion/
        0  03-07-2014 20:45   javacc-6.0/examples/GUIParsing/TokenMgrVersion/
        0  03-07-2014 20:45   javacc-6.0/examples/Interpreter/
        0  03-07-2014 20:45   javacc-6.0/examples/JJTreeExamples/
        0  03-07-2014 20:45   javacc-6.0/examples/JavaCCGrammar/
        0  03-07-2014 20:45   javacc-6.0/examples/JavaGrammars/
        0  03-07-2014 20:45   javacc-6.0/examples/JavaGrammars/1.5/
        0  03-07-2014 20:45   javacc-6.0/examples/JavaGrammars/cpp/
        0  03-07-2014 20:45   javacc-6.0/examples/Lookahead/
        0  03-07-2014 20:45   javacc-6.0/examples/MailProcessing/
        0  03-07-2014 20:45   javacc-6.0/examples/Obfuscator/
        0  03-07-2014 20:45   javacc-6.0/examples/Obfuscator/input/
        0  03-07-2014 20:45   javacc-6.0/examples/Obfuscator/input/package1/
        0  03-07-2014 20:45   javacc-6.0/examples/Obfuscator/input/package2/
        0  03-07-2014 20:45   javacc-6.0/examples/SimpleExamples/
        0  03-07-2014 20:45   javacc-6.0/examples/Transformer/
        0  03-07-2014 20:45   javacc-6.0/examples/VTransformer/
       71  04-04-2007 04:50   javacc-6.0/examples/CORBA-IDL/Hello.idl
    11707  11-04-2007 15:36   javacc-6.0/examples/CORBA-IDL/IDL.jj
     1801  12-04-2006 15:24   javacc-6.0/examples/CORBA-IDL/README
     7115  08-18-2008 17:07   javacc-6.0/examples/GUIParsing/ParserVersion/CalcGUI.java
     3076  12-04-2006 15:24   javacc-6.0/examples/GUIParsing/ParserVersion/CalcInput.jj
     1942  08-18-2008 17:07   javacc-6.0/examples/GUIParsing/ParserVersion/Main.java
     2575  08-18-2008 17:07   javacc-6.0/examples/GUIParsing/ParserVersion/ProducerConsumer.java
     2730  12-04-2006 15:24   javacc-6.0/examples/GUIParsing/ParserVersion/README
     1753  08-18-2008 17:07   javacc-6.0/examples/GUIParsing/ParserVersion/TokenCollector.java
     2238  12-04-2006 15:24   javacc-6.0/examples/GUIParsing/README
     6919  08-18-2008 17:07   javacc-6.0/examples/GUIParsing/TokenMgrVersion/CalcGUI.java
     5161  12-04-2006 15:24   javacc-6.0/examples/GUIParsing/TokenMgrVersion/CalcInput.jj
     5668  08-18-2008 17:07   javacc-6.0/examples/GUIParsing/TokenMgrVersion/CharCollector.java
     1867  08-18-2008 17:07   javacc-6.0/examples/GUIParsing/TokenMgrVersion/Main.java
     2163  08-18-2008 17:07   javacc-6.0/examples/GUIParsing/TokenMgrVersion/MyLexer.java
     2866  03-13-2007 09:35   javacc-6.0/examples/GUIParsing/TokenMgrVersion/README
     2035  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTAddNode.java
     2165  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTAndNode.java
     1957  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTAssignment.java
     2294  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTBitwiseAndNode.java
     1957  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTBitwiseComplNode.java
     2290  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTBitwiseOrNode.java
     2293  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTBitwiseXorNode.java
     1929  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTBlock.java
     2276  10-23-2007 14:18   javacc-6.0/examples/Interpreter/ASTCompilationUnit.java
     2036  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTDivNode.java
     2237  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTEQNode.java
     1877  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTFalseNode.java
     2034  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTGENode.java
     2036  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTGTNode.java
     1871  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTId.java
     2038  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTIfStatement.java
     1897  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTIntConstNode.java
     2034  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTLENode.java
     2033  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTLTNode.java
     2036  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTModNode.java
     2036  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTMulNode.java
     2238  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTNENode.java
     1935  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTNotNode.java
     2160  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTOrNode.java
     2556  04-04-2007 04:41   javacc-6.0/examples/Interpreter/ASTReadStatement.java
     1941  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTStatementExpression.java
     2054  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTSubtractNode.java
     1876  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTTrueNode.java
     2065  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTVarDeclaration.java
     2039  04-04-2007 04:49   javacc-6.0/examples/Interpreter/ASTWhileStatement.java
     2194  04-04-2007 04:41   javacc-6.0/examples/Interpreter/ASTWriteStatement.java
     2538  04-04-2007 04:33   javacc-6.0/examples/Interpreter/MyNode.java
     2722  02-06-2008 02:26   javacc-6.0/examples/Interpreter/Node.java
     2167  12-04-2006 15:24   javacc-6.0/examples/Interpreter/README
     2849  04-04-2007 04:31   javacc-6.0/examples/Interpreter/SPL.java
     6800  10-18-2007 16:49   javacc-6.0/examples/Interpreter/SPL.jjt
      103  06-09-2003 13:46   javacc-6.0/examples/Interpreter/fact.spl
      111  06-09-2003 13:46   javacc-6.0/examples/Interpreter/odd.spl
      137  06-09-2003 13:46   javacc-6.0/examples/Interpreter/sqrt.spl
     2071  04-04-2007 07:07   javacc-6.0/examples/JJTreeExamples/ASTMyID.java
      633  02-28-2011 18:08   javacc-6.0/examples/JJTreeExamples/ASTMyOtherID.java
     3744  04-16-2007 12:23   javacc-6.0/examples/JJTreeExamples/Eg4DumpVisitor.java
     8171  03-13-2007 09:44   javacc-6.0/examples/JJTreeExamples/README
     2867  04-16-2007 12:22   javacc-6.0/examples/JJTreeExamples/build.xml
     3392  04-04-2007 07:06   javacc-6.0/examples/JJTreeExamples/eg1.jjt
     3546  11-02-2007 17:27   javacc-6.0/examples/JJTreeExamples/eg2.jjt
     3553  04-04-2007 07:06   javacc-6.0/examples/JJTreeExamples/eg3.jjt
     3632  04-04-2007 07:06   javacc-6.0/examples/JJTreeExamples/eg4.jjt
    27499  12-04-2006 15:24   javacc-6.0/examples/JavaCCGrammar/JavaCC.jj
    43585  08-23-2008 12:48   javacc-6.0/examples/JavaGrammars/1.5/Java1.5.jj
      191  08-23-2008 12:48   javacc-6.0/examples/JavaGrammars/1.5/JavaGenerics.java
     1214  04-30-2005 10:19   javacc-6.0/examples/JavaGrammars/1.5/Main.java
      418  08-23-2008 12:48   javacc-6.0/examples/JavaGrammars/1.5/MyToken.java
      754  12-27-2003 16:04   javacc-6.0/examples/JavaGrammars/1.5/README
      399  08-20-2004 17:43   javacc-6.0/examples/JavaGrammars/1.5/Test.java
     2033  08-23-2008 12:48   javacc-6.0/examples/JavaGrammars/1.5/build.xml
    17241  12-04-2006 15:24   javacc-6.0/examples/JavaGrammars/Java1.0.2.jj
    17517  12-04-2006 15:24   javacc-6.0/examples/JavaGrammars/Java1.0.2LS.jj
    34226  02-22-2011 10:53   javacc-6.0/examples/JavaGrammars/Java1.1-cpp.jj
    35378  02-22-2011 10:53   javacc-6.0/examples/JavaGrammars/Java1.1.jj
    35273  12-04-2006 15:24   javacc-6.0/examples/JavaGrammars/Java1.1noLA.jj
     9428  12-04-2006 15:24   javacc-6.0/examples/JavaGrammars/OPTIMIZING
     3170  12-04-2006 15:24   javacc-6.0/examples/JavaGrammars/README
      399  08-20-2004 17:43   javacc-6.0/examples/JavaGrammars/Test.java
    34658  08-04-2013 21:46   javacc-6.0/examples/JavaGrammars/cpp/Java1.1.jjt
      538  12-15-2012 11:24   javacc-6.0/examples/JavaGrammars/cpp/Makefile
     1252  12-15-2012 11:24   javacc-6.0/examples/JavaGrammars/cpp/allmain.cc
     1289  08-04-2013 21:46   javacc-6.0/examples/JavaGrammars/cpp/main.cc
      450  10-11-2012 16:47   javacc-6.0/examples/JavaGrammars/cpp/myparser.h
       16  07-23-2012 11:02   javacc-6.0/examples/JavaGrammars/cpp/mytm.h
       21  07-06-2013 10:17   javacc-6.0/examples/JavaGrammars/cpp/token_base.h
     1962  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example1.jj
     2008  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example10.jj
     2057  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example2.jj
     2075  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example3.jj
     2002  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example4.jj
     2079  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example5.jj
     2072  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example6.jj
     2026  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example7.jj
     2090  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example8.jj
     2092  12-04-2006 15:24   javacc-6.0/examples/Lookahead/Example9.jj
    27502  12-04-2006 15:24   javacc-6.0/examples/Lookahead/README
     4408  12-04-2006 15:24   javacc-6.0/examples/MailProcessing/Digest.jj
     4926  12-04-2006 15:24   javacc-6.0/examples/MailProcessing/Faq.jj
     5144  12-04-2006 15:24   javacc-6.0/examples/MailProcessing/README
    10765  12-04-2006 15:24   javacc-6.0/examples/MailProcessing/sampleMailFile
     2812  08-18-2008 17:07   javacc-6.0/examples/Obfuscator/Globals.java
     5331  12-04-2006 15:24   javacc-6.0/examples/Obfuscator/IdsFile.jj
    19327  12-04-2006 15:24   javacc-6.0/examples/Obfuscator/Java1.1.jj
     4525  08-18-2008 17:07   javacc-6.0/examples/Obfuscator/Main.java
     5254  12-04-2006 15:24   javacc-6.0/examples/Obfuscator/MapFile.jj
     9864  08-18-2008 17:07   javacc-6.0/examples/Obfuscator/Obfuscator.java
     4514  12-04-2006 15:24   javacc-6.0/examples/Obfuscator/README
     1846  08-18-2008 17:07   javacc-6.0/examples/Obfuscator/input/package1/Main.java
     1877  08-18-2008 17:07   javacc-6.0/examples/Obfuscator/input/package2/Incr.java
       90  06-09-2003 13:46   javacc-6.0/examples/Obfuscator/maps
       71  06-09-2003 13:46   javacc-6.0/examples/Obfuscator/nochangeids
       75  06-09-2003 13:46   javacc-6.0/examples/Obfuscator/useids
     3997  12-04-2006 15:24   javacc-6.0/examples/README
     2045  04-04-2007 07:58   javacc-6.0/examples/SimpleExamples/IdList.jj
     3964  04-04-2007 07:58   javacc-6.0/examples/SimpleExamples/NL_Xlator.jj
    16278  02-23-2011 18:21   javacc-6.0/examples/SimpleExamples/README
     2512  04-04-2007 07:58   javacc-6.0/examples/SimpleExamples/Simple1.jj
     2085  04-04-2007 07:58   javacc-6.0/examples/SimpleExamples/Simple2.jj
     2283  04-04-2007 07:58   javacc-6.0/examples/SimpleExamples/Simple3.jj
     2212  08-18-2008 17:07   javacc-6.0/examples/Transformer/ASTCompilationUnit.java
     2110  08-18-2008 17:07   javacc-6.0/examples/Transformer/ASTSpecialBlock.java
     2663  12-04-2006 15:24   javacc-6.0/examples/Transformer/README
     4508  08-18-2008 17:07   javacc-6.0/examples/Transformer/SimpleNode.java
    19179  12-04-2006 15:24   javacc-6.0/examples/Transformer/ToyJava.jjt
     1777  12-04-2006 15:24   javacc-6.0/examples/Transformer/divide.toy
     2513  08-18-2008 17:07   javacc-6.0/examples/VTransformer/AddAcceptVisitor.java
    18393  11-07-2007 14:12   javacc-6.0/examples/VTransformer/Java1.1.jjt
     2175  08-18-2008 17:07   javacc-6.0/examples/VTransformer/Main.java
     5773  12-04-2006 15:24   javacc-6.0/examples/VTransformer/README
     4051  08-18-2008 17:07   javacc-6.0/examples/VTransformer/SimpleNode.java
    11615  08-18-2008 17:07   javacc-6.0/examples/VTransformer/UnparseVisitor.java
     1536  12-04-2006 15:24   javacc-6.0/LICENSE
---------                     -------
  1474798                     185 files

C++ codegen seems broken

Whoever is messing with C++ code generator - please doublecheck it with:

examples/JavaGrammar/cpp
just run make clean; make and make sure it compiles and also try and test the generated parser.

For example, right now, I get 100s of errors in the main branch. Looks like jjtree C++ code gen is hosed, Can whoever thinks broke it take a look? I will try and find the CR that broke it later tonight,

/* Generated By:JJTree: Do not edit this line. Node.h Version 7.0 /
/
JavaCCOptions:MULTI=false,NODE_USES_PARSER=false,VISITOR=false,TRACK_TOKENS=false,NODE_PREFIX=AST,NODE_E
XTENDS=,NODE_FACTORY=,SUPPORT_CLASS_VISIBILITY_PUBLIC=true */
#ifndef JAVACC_NODE_H
#define JAVACC_NODE_H

#include
#include "JavaCC.h"
#include "Token.h"

namespace java {
namespace parser {

/* All AST nodes must implement this interface. It provides basic
machinery for constructing the parent and child relationships
between nodes. */

class JavaParser
class Node {
friend class SimpleNode;

Connect nodes with production results

For a production I can define a return object and a corresponding parse node. Is there a possibility to connect both automatically? The manual way I know and use.

JavaCC parser fails on try no catch nor finally

Hi
a try / catch / finally must contain at least on catch or one finally but JavaCC fails with a NPE after the error message
grammar .jj:
void ko2() :{}{
try { "C" }
}
Output:
[java] Java Compiler Compiler Version 7.0.0 (Parser Generator)
[java] Warning: Line 10, Column 3: Command line setting of "OUTPUT_DIRECTORY" modifies option value in file.(type "javacc" with no arguments for help)
[java] Reading from file D:\Devs\GitRepo\jtb\src\test\jj/grammars/j/TinyGrammar.jj . . .
[java] Error: Line 493, Column 3: Try block must contain at least one catch or finally block.
[java] Exception in thread "main" java.lang.NullPointerException
[java] at org.javacc.parser.JavaCCParser.expansion(JavaCCParser.java:833)
[java] at org.javacc.parser.JavaCCParser.expansion_choices(JavaCCParser.java:773)
[java] at org.javacc.parser.JavaCCParser.bnf_production(JavaCCParser.java:550)
[java] at org.javacc.parser.JavaCCParser.production(JavaCCParser.java:404)
[java] at org.javacc.parser.JavaCCParser.javacc_input(JavaCCParser.java:229)
[java] at org.javacc.parser.Main.mainProgram(Main.java:218)
[java] at org.javacc.parser.Main.main(Main.java:154)

Update readme

The Readme reads "Copyright (c) 2006, Sun Microsystems, Inc.".
As far as I know Sun does not exist anymore, should that be updated?

Moreover, should the file be converted to Markdown?

8.0.0: CPPCODE is not anymore recognized

Hi

The following snippet that compiles fine with 7.0.4

PARSER_END(Typer)
CPPCODE
void skipbracket() {
  Token* tok;
  int nesting = 1;
  while (true) {
    tok = getToken(1);
    if (tok->kind() == LBRACKET) nesting++;
    if (tok->kind() == RBRACKET) {
      nesting--;
         if (nesting == 0) break;

does not compile anymore with 8.0.0

Z:\git\asn1cpp\code\ASN1Typer>java -cp z:\git\javacc-8.0\target\javacc.jar javacc -output_directory=gen Typer.jj
Java Compiler Compiler Version 8.0.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file Typer.jj . . .
org.javacc.parser.ParseException: Encountered " "void" "void "" at line 81, column 1.
Was expecting one of:
    "*" ...
    "&" ...
    <IDENTIFIER> ...
    "<" ...
    "." ...
    "::" ...
    "[" ...

Detected 1 errors and 0 warnings.

[6.1.3] The code for the static initializer is exceeding the 65535 bytes limit

I'm having a big grammar (https://github.com/phax/ph-css/blob/master/ph-css/src/main/jjtree/ParserCSS30.jjt) and when I compile it with DEBUG_PARSER=true and DEBUG_TOKEN_MANAGER=true I get the Java error The code for the static initializer is exceeding the 65535 bytes limit in the generated TokenManager class.

A simply solution would be to put the static members protected static final int[][][] statesForState´ and protected static final int[][] kindForState` in static inner classes and reference them from the respective with the qualified calls.

So current it is like this:

public class XXTokenManager ... {
...
int[] stateSet = statesForState[curLexState][vec[i]];
...
protected static final int[][][] statesForState = { ...};
protected static final int[][] kindForState = {...};
}

The proposed solution is like this:

public class XXTokenManager ... {
...
int[] stateSet = States.statesForState[curLexState][vec[i]];
...
protected static final class States {
  protected static final int[][][] statesForState = { ...};
}
protected static final class Kinds  {
  protected static final int[][] kindForState = {...};
}
}

Modern template creates non-compiling code

Affects JavaCC 6.1.3 and 7.0.2

The line throw new RuntimeException("Missing return statement in function"); is not generated when the modern template is active (see Options.isLegacyExceptionHandling())

The source of the error is https://github.com/javacc/javacc/blob/master/src/main/java/org/javacc/parser/ParseEngine.java#L709-L712
The "if" in line 709 must be removed, because currently the code line is only generated, when the legacy exception handling is enabled (so this block is never entered if the modern template is used!)

Edit: here is a compiler output when using JavaCC 7.0.2 with ph-css and the modern template:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default
-compile) on project ph-css: Compilation failure: Compilation failure:
[ERROR] /P:/git/ph-css/ph-css/target/generated-sources/javacc/com/helger/css/parser/ParserCSS30.java
:[586,1] missing return statement
[ERROR] /P:/git/ph-css/ph-css/target/generated-sources/javacc/com/helger/css/parser/ParserCSS30.java
:[3469,1] missing return statement
[ERROR] -> [Help 1]

Generated code does not compile when missing lookahead or too small in try / catch

Hi

grammar .jj:

void ko() :{}{
try { "A" "B" | "A" "C" } // -> warning common prefix "A" use lookahead of 2
catch (Exception e) { System.out.println("... Should not occurr " + e); }
}
void ok() :{}{
try { LOOKAHEAD(2) "A" "B" | "A" "C" }
catch (Exception e) { System.out.println("... Should not occurr " + e); }
}
void ko1() :{}{
try { LOOKAHEAD(1) "A" "B" | "A" "C" } // note 1, not 2
catch (Exception e) { System.out.println("... Should not occurr " + e); }
}

produces a badly generated code for expansion choice with a lookahead warning or too small

static final public
void ko() throws ParseException {
try {
switch ((jj_ntk==-1)?jj_ntk_f():jj_ntk) {
case 15:{
jj_consume_token(15);
jj_consume_token(16);
break;
}{ // -> start of unreachable code
jj_consume_token(15);
jj_consume_token(17);
break;
}// -> end of unreachable code
default:
jj_la1[7] = jj_gen;
jj_consume_token(-1);
throw new ParseException();
}
} catch (Exception e) {
System.out.println("... Should not occurr " + e);
}
}

static final public void ok() throws ParseException {
try {
if (jj_2_1(2)) {
jj_consume_token(15);
jj_consume_token(16);
} else {
switch ((jj_ntk==-1)?jj_ntk_f():jj_ntk) {
case 15:{
jj_consume_token(15);
jj_consume_token(17);
break;
}
default:
jj_la1[8] = jj_gen;
jj_consume_token(-1);
throw new ParseException();
}
}
} catch (Exception e) {
System.out.println("... Should not occurr " + e);
}
}
static final public void ko1() throws ParseException {
try {
switch ((jj_ntk==-1)?jj_ntk_f():jj_ntk) {
case 15:{
jj_consume_token(15);
jj_consume_token(16);
break;
}{ // -> start of unreachable code
jj_consume_token(15);
jj_consume_token(17);
break;
} // -> end of unreachable code
default:
jj_la1[9] = jj_gen;
jj_consume_token(-1);
throw new ParseException();
}
} catch (Exception e) {
System.out.println("... Should not occurr " + e);
}
}

PEG: Extends JavaCC to support the PEG paradigm

Hi

Bryan Ford has proposed a different way to parse language expressed by a BNF like grammar, known as PEG. This request is proposing to use the code base of JavaCC to provide the generation of PEG parser/lexer in Java and in C++. The syntaxe of PEG grammar is somewhat exotic and an alternative grammar syntax know as LEG much closer to the EBNF syntax recognized by JavaCC would be the best choice. See greg for the detailled differences.

Compiler error in head

Your project setup uses Java 1.5 as a target but uses BitSet.toLongArray in class TableDrivenJavaCodeGenerator. This method toLongArray is first available in JDK 1.7

c++ generated parser doesn't support international characters

Problem is with some international characters.

How to reproduce the problem?
Download latest javacc source (master eb4455b)
build javacc with ant

Build C++ JavaGrammar example
cd examples/JavaGrammars/cpp
make

Parse java file from HelloWorld.zip
./javaparser HelloWorld.java

Got several errors reported

error: 10
Expecting ; at: 7:35 but got (
Expecting } at: 7:35 but got (
Expecting } at: 7:35 but got (
Expecting EOF at: 7:35 but got (

Problem is with definition of JAVACC_CHAR_TYPE as char which is in C/C++ signed and comparision JAVACC_CHAR_TYPE in JavaParserTokenManager.cc else if (curChar < 128) which is always true.

Modernise SimpleNode accessibility

I just realised that I don't know anything about the politics or reasons behind the fork. So there is no reason why I shouldn't also extend this offer to you.

If you see value in what I am suggesting at tulipcc#16 I could also roll the patch here.

Slow Performance: JavaCharStream.java FillBuff

I'm a Beanshell user which using javacc dynamically. The following throw new java.io.Exception() always copy the stack trace in super class' constructor. Could it implement as a final static exception in JavaCharStream.java? I think it's very expensive for checking the end event of stream.

https://github.com/javacc/codegenerator/blob/master/java/src/main/resources/templates/JavaCharStream.template#L158

      if ((i = inputStream.read(nextCharBuf, maxNextCharInd,
                                          4096 - maxNextCharInd)) == -1)
      {
        inputStream.close();
        throw new java.io.IOException();
      }

The same problem in Parser.java https://github.com/javacc/codegenerator/blob/235d5e1dfb509eae6fb32afffe9e6758f7c89a83/java/src/main/java/org/javacc/java/ParserCodeGenerator.java#L717.

java.lang.IllegalArgumentException when parser used in eclipse

I am trying to use a javaCC generated parser into a CodenameOne (https://www.codenameone.com/) java application. The proplem I have is that, when I run this app from Eclipse, the parser throw the following error:

java.lang.IllegalArgumentException: [c@550d68db is not a valid WeekDay
	at org.tomlab.mymap.common.openinghours.WeekDayRange.setEndDay(WeekDayRange.java:189)
	at org.tomlab.mymap.common.openinghours.OpeningHoursParser.weekday_range(OpeningHoursParser.java:402)
	at org.tomlab.mymap.common.openinghours.OpeningHoursParser.weekday_selector(OpeningHoursParser.java:480)
	at org.tomlab.mymap.common.openinghours.OpeningHoursParser.rule(OpeningHoursParser.java:988)
	at org.tomlab.mymap.common.openinghours.OpeningHoursParser.rules(OpeningHoursParser.java:1033)
	at org.tomlab.mymap.common.openinghours.OpeningHours.parseOpeningHours(OpeningHours.java:43)
	at org.tomlab.mymap.MyApplication.start(MyApplication.java:130)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.codename1.impl.javase.Executor$1$1.run(Executor.java:126)
	at com.codename1.ui.Display.processSerialCalls(Display.java:1130)
	at com.codename1.ui.Display.mainEDTLoop(Display.java:925)
	at com.codename1.ui.RunnableWrapper.run(RunnableWrapper.java:120)
	at com.codename1.impl.CodenameOneThread.run(CodenameOneThread.java:176)

Now, where this is weird is that if I run the exact same application from inside Netbeans, everything works fine! (the parser do not throw any error and the String I am giving it is correctly parsed).
So I don't know why the compiled parser is failing when my app is run from inside Eclipse and not when run from Netbeans...
The value [c@550d68db returned in the error log is the value from a String that is supposed to contain the value Fr here (So why it contains something that seems to be an object reference in that case is a mystery to me). Do anyone have an idea of what might be the cause of this strange behaviour (the token image to contain what seems to be an object reference rather than the expected value of the token)?
I tried to look at the parser code generated by javaCC to debug but this is too much "obfuscated" to be easily understandable (the jj_consume_token function calls some jj_* functions which are all name coded with numbers or letters). I even don't know exactly how the parser is functioning as in my jj file for example I have some token defined like:

TOKEN :
{
  < WEEKDAY :
    "Mo"
  | "Tu"
  | "We"
  | "Th"
  | "Fr"
  | "Sa"
  | "Su" >
  {
          matchedToken.image = Util.capitalize(image.toString());
  }
| < WEEKDAY3 :
    "Mon"
  | "Tue"
  | "Wed"
  | "Thu"
  | "Fri"
  | "Sat"
  | "Sun" >
  {
          matchedToken.image = Util.capitalize(image.toString()).substring(0, 2);
  }
...

but if I look at the parser generated code I can't find the Fr or Fri Strings (or any other day) anywhere. So how is the parser even knowing which are the possible token values. Do it read it from the jj file at startup each time (but I thought the jj file could be dropped once the parser is generated)? If anyone who knows how javaCC works could enlighten me on this point...

Commit history

The commit history from this long running project has not been kept in the move to git/github. This information is important and a source of pride to the contributors. Please make every effort to retrieve it.

Feature: allow the specification of the value for the parser constants

Hi

For the C++ generation, JavaCC generates a ParserConstants file which is defining the token's kind as a list of const int TOKEN = as for example:

With such TOKEN declaration:

TOKEN							:
{
  <#NA				: ~["-","\r","\n"] >
| <#EOL				: ("\n" | "\r" | "\r\n") >
}
TOKEN 				:
{
  <CTAG				: "/>">
| <ETAG				: "</">
| <LBRACKET 			: "["> 
| <RBRACKET 			: "]">
| <LBRACE 			: "{">
| <RBRACE 			: "}">

JavaCC generates:

/* Generated By:JavaCC: Do not edit this line. TyperConstants.java */
/**
 * Token literal values and constants.
 * Generated by org.javacc.parser.OtherFilesGen#start()
 */
#ifndef TYPERCONSTANTS_H
#define TYPERCONSTANTS_H
#include "JavaCC.h"

namespace ASN1 {
namespace Typer {
/** End of File. */
const  int _EOF = 0;
/** RegularExpression Id. */
const  int NA = 9;
/** RegularExpression Id. */
const  int EOL = 10;
/** RegularExpression Id. */
const  int CTAG = 13;
/** RegularExpression Id. */
const  int ETAG = 14;
/** RegularExpression Id. */
const  int LBRACKET = 15;

This issue is requesting to permit the customization of the integer value given to each token's const int as for example
TOKEN :
{
<#NA : ~["-","\r","\n"] > : USER_NA
| <#EOL : ("\n" | "\r" | "\r\n") > : USER_EOL
}
TOKEN :
{
<CTAG : "/>"> : USER_CTAG
| <ETAG : "</"> : USER_ETAG
| <LBRACKET : "["> : USER_LBRACKET
| <RBRACKET : "]"> : USER_RBRACKET
| <LBRACE : "{"> : USER_LBRACE
| <RBRACE : "}"> : USER_RBRACE

so that the generated constant file looks like

/* Generated By:JavaCC: Do not edit this line. TyperConstants.java /
/
*

  • Token literal values and constants.
  • Generated by org.javacc.parser.OtherFilesGen#start()
    */
    #ifndef TYPERCONSTANTS_H
    #define TYPERCONSTANTS_H
    #include "JavaCC.h"

namespace ASN1 {
namespace Typer {
/** End of File. /
const int _EOF = 0;
/
* RegularExpression Id. /
const int NA = USER_NA;
/
* RegularExpression Id. /
const int EOL = USER_EOL ;
/
* RegularExpression Id. /
const int CTAG = USER_CTAG ;
/
* RegularExpression Id. /
const int ETAG = USER_ETAG ;
/
* RegularExpression Id. */
const int LBRACKET = USER_LBRACKET ;

8.0.0/cpp: SimpleNode is not generated anymore

Hi

Be;low the classes generated by JavaCC 7.0.2

Z:\git\SPLC\JJTree\VST>..\..\gradlew compileJJtree
:JJTree:VST:compileJjtree
Java Compiler Compiler Version 7.0.2 (Tree Builder)
(type "jjtree" with no arguments for help)
Reading from file Z:\git\SPLC\JJTree\VST\jjt\SPL.jjt . . .
opt:c++
File "Node.h" does not exist.  Will create one.
File "SimpleNode.h" does not exist.  Will create one.
File "SimpleNode.cc" does not exist.  Will create one.
File "ASTDivNode.h" does not exist.  Will create one.
File "ASTNENode.h" does not exist.  Will create one.
File "ASTCompilationUnit.h" does not exist.  Will create one.
File "ASTMulNode.h" does not exist.  Will create one.
File "ASTIntConstNode.h" does not exist.  Will create one.
File "ASTWriteStatement.h" does not exist.  Will create one.
File "ASTBitwiseComplNode.h" does not exist.  Will create one.
File "ASTBitwiseXorNode.h" does not exist.  Will create one.
File "ASTOrNode.h" does not exist.  Will create one.
File "ASTBitwiseAndNode.h" does not exist.  Will create one.
File "ASTNotNode.h" does not exist.  Will create one.
File "ASTGENode.h" does not exist.  Will create one.
File "ASTId.h" does not exist.  Will create one.
File "ASTTrueNode.h" does not exist.  Will create one.
File "ASTAssignment.h" does not exist.  Will create one.
File "ASTModNode.h" does not exist.  Will create one.
File "ASTGTNode.h" does not exist.  Will create one.
File "ASTSubtractNode.h" does not exist.  Will create one.
File "ASTLTNode.h" does not exist.  Will create one.
File "ASTBitwiseOrNode.h" does not exist.  Will create one.
File "ASTLENode.h" does not exist.  Will create one.
File "ASTReadStatement.h" does not exist.  Will create one.
File "ASTEQNode.h" does not exist.  Will create one.
File "ASTFalseNode.h" does not exist.  Will create one.
File "ASTAddNode.h" does not exist.  Will create one.
File "ASTVarDeclaration.h" does not exist.  Will create one.
File "ASTAndNode.h" does not exist.  Will create one.
File "ASTDivNode.cc" does not exist.  Will create one.
File "ASTNENode.cc" does not exist.  Will create one.
File "ASTCompilationUnit.cc" does not exist.  Will create one.
File "ASTMulNode.cc" does not exist.  Will create one.
File "ASTIntConstNode.cc" does not exist.  Will create one.
File "ASTWriteStatement.cc" does not exist.  Will create one.
File "ASTBitwiseComplNode.cc" does not exist.  Will create one.
File "ASTBitwiseXorNode.cc" does not exist.  Will create one.
File "ASTOrNode.cc" does not exist.  Will create one.
File "ASTBitwiseAndNode.cc" does not exist.  Will create one.
File "ASTNotNode.cc" does not exist.  Will create one.
File "ASTGENode.cc" does not exist.  Will create one.
File "ASTId.cc" does not exist.  Will create one.
File "ASTTrueNode.cc" does not exist.  Will create one.
File "ASTAssignment.cc" does not exist.  Will create one.
File "ASTModNode.cc" does not exist.  Will create one.
File "ASTGTNode.cc" does not exist.  Will create one.
File "ASTSubtractNode.cc" does not exist.  Will create one.
File "ASTLTNode.cc" does not exist.  Will create one.
File "ASTBitwiseOrNode.cc" does not exist.  Will create one.
File "ASTLENode.cc" does not exist.  Will create one.
File "ASTReadStatement.cc" does not exist.  Will create one.
File "ASTEQNode.cc" does not exist.  Will create one.
File "ASTFalseNode.cc" does not exist.  Will create one.
File "ASTAddNode.cc" does not exist.  Will create one.
File "ASTVarDeclaration.cc" does not exist.  Will create one.
File "ASTAndNode.cc" does not exist.  Will create one.
File "SPLParserTree.h" does not exist.  Will create one.
File "SPLParserTreeConstants.h" does not exist.  Will create one.
File "SPLParserVisitor.h" does not exist.  Will create one.
File "JJTSPLParserState.h" does not exist.  Will create one.
File "JJTSPLParserState.cc" does not exist.  Will create one.
Annotated grammar generated successfully in Z:\git\SPLC\JJTree\VST\gen\tmp\SPL.jj

and below, the classes generated by JavaCC 8.0.0:

Z:\git\SPLC\JJTree\VST>..\..\gradlew compileJJtree
:JJTree:VST:compileJjtree
Java Compiler Compiler Version 8.0.0 (Tree Builder)
(type "jjtree" with no arguments for help)
Warning: VISITOR_RETURN_TYPE option will be ignored since VISITOR is false
Reading from file Z:\git\SPLC\JJTree\VST\jjt\SPL.jjt . . .
File "Node.h" does not exist.  Will create one.
File "SPLParserTree.h" does not exist.  Will create one.
File "SPLParserTree.cc" does not exist.  Will create one.
File "SPLParserTreeConstants.h" does not exist.  Will create one.
File "SPLParserVisitor.h" does not exist.  Will create one.
File "JJTSPLParserState.h" does not exist.  Will create one.
File "JJTSPLParserState.cc" does not exist.  Will create one.
Annotated grammar generated successfully in Z:\git\SPLC\JJTree\VST\gen\tmp\SPL.jj

The SPL.jjt grammar: SPL.jjt.txt

Modular composition of grammars

Here it is stated:

"In a future version of JavaCC we will have support for modular composition of grammars"

I would love to hear more about that because this would help us a ton at JavaParser to support the possibility of extending Java.
Any concrete plan for that? Any hackish way we can achieve that with the current version of JavaCC? Thoughts?

RCharacterList line 487

Line 487 should be ((CharacterRange)newDesc.get(j)).setLeft((char)(range.getRight() + 1));
instead it is ((CharacterRange)newDesc.get(j)).setRight((char)(range.getLeft() + 1)); causing an overlapping character range to be deleted for it is folded inward, thus omitting it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.