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

Related tags

javacc
Overview

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.

Example

This 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:

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

Examples of illegal strings are:

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

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() ] "}"
}

Output

$ java Example
{{}}<return>
$ 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)
$ 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

Follow the steps here to get started with JavaCC.

This guide will walk you through locally building the project, running an existing example, and setup to start developing and testing your own JavaCC application.

Download & Installation

JavaCC 7.0.10 is our latest stable release.

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

For all previous releases, please see stable releases.

The GitHub 8.0 branch contains the next generation of JavaCC that splits the frontend -- the JavaCC parser -- from the backends -- the code generator targeted for Java, C++ &and C# --. Status of JavaCC is experimental and not production ready.

Installation

To install JavaCC, navigate to the download directory and type:

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

Then place the binary javacc-7.0.10.jar in a new target/ folder, and rename to javacc.jar.

Once you have completed installation add the scripts/ directory in the JavaCC installation 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.10/ directory:

chmod +x scripts/javacc

Building JavaCC from Source

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

Prerequisites for building JavaCC:

  • 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)
$ git clone https://github.com/javacc/javacc.git
$ cd javacc
$ ant

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

Developing JavaCC

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

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


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

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

    Following code lines seem to cause lookahead problems:

    https://github.com/javacc/javacc/blob/ca275162a5d98d3bd4f2317efd9c19ad2144b5ef/src/main/java/org/javacc/parser/ParseEngine.java#L1377-L1381

    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.

    opened by zhztheplayer 35
  • Add Gradle build scripts

    Add Gradle build scripts

    This is almost feature-complete, so feel free to try it out.

    See GitHub Actions CI here: https://github.com/vlsi/javacc/actions

    Overview

    This PR implements all the tasks that existed previously (in both Ant and Maven), and the PR adds lots of features:

    • Project loads to IDE automatically
    • Reproducible builds (the resulting jar, zip, and tar files are the same in case the same Java version is used)
    • Build script provides help for the command line
    • Code style is managed via Autostyle. For now, it trims trailing whitespace. It prints human-understandable messages on failures, and it provides a command to automatically fix violations.
    • Release to Central is just a couple of commands (prepareVote + publishDist)
    • JavaCC is incremental now. In other words, if a clas (or grammar) is changed, then one can launch ./gradlew test, and Gradle would build the jar before it starts testing

    CI

    GitHub Actions (Linux, macOS, Windows): https://github.com/vlsi/javacc/actions Travis (Linux): https://travis-ci.com/javacc/javacc/pull_requests

    Note: Travis builds with Java 8, and Java 11 fail for some reason. Java 8 gets blocked at test/javaFiles for some reason. Java 11 fails to download junit3 (it is probably Maven Central or Travis issue)

    Files to be removed as the build is migrated to Gradle

    Note: the migration makes Maven and some Ant files obsolete, so I would recommend to remove them, otherwise it would take significant time to maintain multiple build scripts.

    The last commit in the PR removes the files. If you want to compare how Ant or Maven build worked, then skip Remove redundant build files commit.

    • **/pom.xml, mvn.bat. Those files are obsolete
    • /build.xml fully (?) migrated to Gradle + part of it are moved to examples/build.xml and {examples,test}/build.gradle.kts
    • lib/**. Dependency management is migrated to Gradle, so lib is obsolete

    Testing JavaCC

    ./gradlew test builds the project, and launches all the tests.

    test and examples folders

    I would recommend to eventually migrate the tests to JUnit (or something like that). Current folder structure makes maintenance really complicated, so I would suggest to execute those folders via Ant (see ./gradlew :javacc-examples:antTest, and ./gradlew :javacc-test:antTest)

    Review pom files

    pom.xml are generated on the fly, and ./gradlew generatePom can be used to review the pom. It will generate the pom files to build/publications/*/pom*.xml

    Release to Central

    CI job (validates that publish to Central tasks work): https://github.com/vlsi/vlsi-release-plugins/runs/406605437

    Instructions: https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/stage-vote-release-plugin#making-a-release-candidate

    TL;DR:

    # -Pgh means "push to GitHub + Sonatype"
    # if -Pgh is omitted, then it would expect asflike-release-environment and push to localhost
    
    ./gradlew prepareVote -Prc=1 -Pgh # prepares a release candidate
    
    ./gradlew publishDist -Prc=1 -Pgh # promotes the candidate
    

    Note: there's a playground that launches mock implementations of Git and Nexus in a Docker container, so you can try how release works without pushing to real GitHub / Sonatype servers.

    fixes #141

    opened by vlsi 25
  • Make a release

    Make a release

    We're all waiting :-) https://github.com/phax/ph-javacc-maven-plugin/issues/2

    opened by matozoid 18
  • 8.0.0/cpp: SimpleNode is not generated anymore

    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

    opened by zosrothko 15
  • Use Gradle for the build

    Use Gradle for the build

    Hi,

    I see you have code movement in 8.0.0 branch, so I wonder what do you think of using Gradle as the build system?

    It makes lots of things simpler to do (e.g. when compared with Ant and Maven), it and it improves development experience.

    I've migrated Apache JMeter from Ant to Gradle, and Apache Calcite from Maven to Gradle. In both cases, it resulted in significant improvements when it comes to day-to-day development. In both cases, Gradle made it simpler to release new versions.

    opened by vlsi 12
  • Spaghetti code fix ?

    Spaghetti code fix ?

    Simple change to create "non nesting" logic. Existing solution created if (...) -> if (...) -> if (...) ->if (...) multiple nested construction. I stumbled on that when compiler raised error of too big level of if-nesting (JavaCC created nested logic higher than 256 if i remember correctly) ...

    opened by Risavk 11
  • Codegenerator implementation for C++

    Codegenerator implementation for C++

    One-to-one migration from the CppOutput to the C++ CodeGenerator. The CppOutput mechanism is still available for crosschecks. The next step is to remove all CPP parts from the core. Should we do the same for Java?

    opened by mbrigl 10
  • DFA behaves differently on v.8.0.0

    DFA behaves differently on v.8.0.0

    Using following test-grammar and applying the tokenizer on "NS.Attr IS .56"; version 7 and version 8 return different results. The result of version 7 is the expected:

    • Version 7: "ATTR_TOKEN" "DOT" "ATTR_TOKEN" "EQUALS" "DECIMAL_TOKEN" NS . Attr eq .56
    • Version 8: "ATTR_TOKEN" "DOT" "ATTR_TOKEN" "EQUALS" "DOT" "DECIMAL_TOKEN" NS . Attr eq . 56
    SKIP :
    {
      "\u0020"	/* Space */
    }
    
    TOKEN:
    {
      < DOT : "." >
    | < INTEGER_TOKEN : "0" | [ "1"-"9" ] (< DIGIT >) * >
    | < DECIMAL_TOKEN : "NaN" | "Infinity" | < DECIMAL > | < INTEGER_TOKEN > >
    
    | < #DIGIT :	["0"-"9"] >
    | < #DECIMAL :	("0" | ["1"-"9"] (< DIGIT >) * ) ? "." (< DIGIT >)+ >
    }
    
    
    TOKEN [ IGNORE_CASE ] :
    {
      < EQUALS : "eq" >
    | < NULL_TOKEN : "NULL" >
    | < ATTR_TOKEN : ( ["a"-"z"] )+ >
    }
    
    void compileExpression() :
    {}
    {
      parseName()
      < EQUALS >
      (
        < NULL_TOKEN >
      | < DECIMAL_TOKEN > )
      < EOF >
    }
    
    void parseName() :
    {}
    {
      < ATTR_TOKEN >
      (
    	< DOT > parseName()) ?
    }
    
    opened by mbrigl 8
  • Discuss: javax.tools.JavaCompiler or Janino for grammar tests

    Discuss: javax.tools.JavaCompiler or Janino for grammar tests

    See https://github.com/javacc/javacc/pull/143#issuecomment-578058816

    /cc @martinswanson

    A part of JavaCC testing complexity comes from the fact that it requires Java compiler to compile the generated grammar.

    The current tests are written in Ant build files, which makes it complicated to debug, understand, maintain, etc, etc.

    I suggest that most tests should be written like unit tests, so they can be executed from IDE.

    I see the following possibilities: A) javax.tools.JavaCompiler can be used since Java 1.6. That is the compiler can be accessed programatically. Then a test can first call JavaCC to generate the code, then test framework compiles it, then it executes it.

    B) https://github.com/janino-compiler/janino can probably be used as well. They have https://janino-compiler.github.io/janino/apidocs/org/codehaus/janino/JavaSourceClassLoader.html which enables to use Java source files as if it were compiled bytecode.

    C) Eclipse Compiler for Java (ECJ) is an option as well.

    D) https://github.com/google/compile-testing

    Any thoughts?

    opened by vlsi 8
  • javacc.org is out of date

    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?

    opened by HoldYourWaffle 8
  • Create equivalent to lex's REJECT action

    Create equivalent to lex's REJECT action

    Occasionally it is very useful to reject a regex match and force the lexer to find a different match.

    For example, matching dates with a pattern such as ([0-9][0-9][0-9][0-9])-([1-9]|1[0-2])-([1-9]|[12][0-9]|3[01]), it is possible to match invalid dates such as 2021-02-29 or 2020-06-31. While a much more complex pattern to reject these matches is possible, it's much easier to do something like:

        < DATE: ["0"-"9"]["0"-"9"]["0"-"9"]["0"-"9"] "-" ( ["1"-"9"] | "1" ["0"-"2"] ) "-" ( ["1"-"9"] | ["1","2"]["0"-"9"] | "3" ["0","1"]) > {
          try {
            value = LocalDate.parse(token.image, dateFormatter);
          } catch (DateTimeParseException e) {
            REJECT;
          }
        }
    

    which in lex would abort the current match and restart parsing to match an alternative rule. I was not able to find an equivalent in the JavaCC documentation.

    opened by pstemari 1
  • Version on javacc.org

    Version on javacc.org

    On the javacc.org there are still quite a few references to version 7.0.9 though I think this should be 7.0.10.

    (Unfortunately I could not reopen the issue #122)

    opened by albert-github 1
  • Is the STRING_LITERAL lexer rule incomplete in the tutorial?

    Is the STRING_LITERAL lexer rule incomplete in the tutorial?

    Hello, I am currently writing a JavaCC Netbeans module. I used the official JavaCC grammar on your homepage. I think that the STRING_LITERAL

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

    is incomplete. When my module highlights the tokens, unicode charaters "\uxxxx" are not identified correctly. I think, there is a 'u' missing in the token rule. I thinks it should be like this...

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

    opened by Equilibrium0102 0
  • A tutorial problem

    A tutorial problem

    https://javacc.github.io/javacc/tutorials/lookahead.html#example5]

    void BC() : {} { "b" [ LOOKAHEAD( { getToken(1).kind == C && getToken(2).kind != C } ) <C:"c"> ] } Is the second condition getToken(2).kind == C ?

    opened by xuexiaowengh 0
  • Type parameters in expansion_unit ?

    Type parameters in expansion_unit ?

    Hi In https://github.com/javacc/javacc/blob/master/src/main/javacc/JavaCC.jj, around line 1305, the grammar shows optional TypeParameters for the production (method, not class). Why is it there? For C++? How can they appear in Java? Thanks.

    opened by MarcMazas 2
  • C# Example

    C# Example

    Can you provide an example on how to generate C# output from jjt?

    opened by mutigozel 8
  • Add Kotlin support

    Add Kotlin support

    Kotlin is very perspective language and similar with Java. It will be cool to generate Kotlin from JavaCC grammar.

    opened by rusnasonov 1
  • DEPTH_LIMIT compilation error

    DEPTH_LIMIT compilation error

    We would like to use the DEPTH_LIMIT option but it seems to be not supported. The generated code is missing the definition of jj_depth_error variable and as there is actually no code to generate it. What is the current status of the DEPTH_LIMIT option?

    ERROR] COMPILATION ERROR : 
    [INFO] -------------------------------------------------------------
     symbol: variable jj_depth_error
    
    opened by frajt 1
  • Dockerfile

    Dockerfile

    I have (mostly for my own purposes), created a Dockerfile for JavaCC. I don't know if there would be interest to incorporate it into this repository (if so I could open a PR) or link to it?

    opened by mbg 0
Releases(javacc-7.0.10)
The fast scanner generator for Java™ with full Unicode support

JFlex JFlex is a lexical analyzer generator (also known as scanner generator) for Java. JFlex takes as input a specification with a set of regular exp

JFlex 410 Sep 17, 2021
A simple hierarchical state machine compiler that generates C.

Makina is a hierarchical state machine source-to-source translator. It takes state machine descriptions as input and produces C language implementations of those state machines.

Colin Holzman 112 Aug 6, 2021