What's better, ANTLR or JavaCC? [closed]

Question

Concerns are documentation/learnability, eclipse integration, tooling, community support and performance (in roughly that order).

Ragan

and add sablecc also – Ihs

Rekex - grammar as algebraic datatypes - github.com/zhong-j-yu/rekex – Allonge

Answer 1

There are a couple of alternatives you shouldn't rule out:

• JParsec is a parser combinator framework that allows you to construct your parser entirely from code.
• Scala's parser combinator framework addresses a similar concern; however, Scala's syntax makes all of this much more readable.
• Then there's also the parser combinator framework done by John Metsker, for his book Building Parsers With Java; I don't remember exactly where the library is, but it was at least floating around on the Internet in the past. It addresses the same concern: you don't define your grammar and token definitions in a separate non-Java file; instead, it's all Java.
• Fortress, the programming language Sun has been working on for years now seems to be build on this toolkit: Rats. I don't have much information, but I reckon if they use it for their new programming language, it probably has some interesting features.

In general, I get the impression that the years of the code generators are over. If I would be you, I would use Scala's parser combinator toolkit. Basically, any IDE supporting Scala, also 'supports' this parser combinator framework. Performance is good, AFAICT.

By the way, ANTLR has quite decent IDE support, as an Eclipse plugin (but perhaps there's also something in IntelliJ - I don't remember.) So, if you would opt for the classic approach of defining your lexical analyzer and parser outside of your language, then ANTLR should be your choice, I think. It has the biggest mindshare among Java developers, there is tool support, and there is a great book by the author of ANTLR. I don't think any of the other toolkits can claim that.

Chesney

found one value adding of parsercc, the structure extraction logic could be done together when parsing, thus avoided extra cycles revisiting the parsing tree. compared with antlr – Pampa

Is their days are over because they won't stop your development in the infinite stack overflow error? Parser generators check your grammar for left recursion at compile time and, moreover, expose the circular chains to you when detect them. Now, you say that this is obsolete and we must throw it into the trash. How much of parser-building experience do you have if even me, with almost 0 experience, understand how impossible it is to deal with left recursion with parser combinators? – Cymbre

Parser combinators can detect the left recursion only at runtime if you are lucky to supply unfortunate test input and all error reporting is the stack overflow somewhere in the parser combinator code (it won't even show you your parser method invocations to get the idea which rules may recur) instead of the clear dependency chain that 'obsolete' technology provides to you? – Cymbre

I found "Building Parsers with Java" code examples at xp123.com/oozinoz/bpwj.htm – Reichstag

Answer 2

To a first approximation, what's really going to matter to you in practice is how convenient and intuitive the notation is to your eyes.

Having said that, I'd done projects with ANTLR and JavaCC, and found ANTLR to be awfully heavyweight for most things.

Fiasco

Agreed, ANTLR seems to have better tooling support but JavaCC produces concise code that compiles down to less than 50K on average with no external .jar dependencies. – Propose

Answer 3

With respect to the concerns you mentioned, I'd suggest that JavaCC was a better choice. It's quicker and easier for a Java developer to learn (the syntax is extremely similar to ordinary Java), the documentation is comprehensive, and the Eclipse integration is adequate.

Surface

Answer 4

ANTLR is more fully featured: it is a much more out the box compiler compiler - lexing, parsing, AST, tree transformations and code generation.

For JavaCC, it is much more a Parser generator than a compiler compiler. AST support is provided through another lib called JJTree.

Suziesuzuki

JTB ("Java Tree Builder") is an alternative for producing ASTs. – Tungsten

Answer 5

A concrete advantage ANTLR has over JavaCC is that it has generators for languages other than Java. This might make porting your language to other places much easier.

Museum

Answer 6

I second jamesh above.

ANTLR is more fully featured: it is a much more out the box compiler compiler - lexing, parsing, AST, tree transformations and code generation.

For JavaCC, it is much more a Parser generator than a compiler compiler. AST support is provided through another lib called JJTree.

From my personal experience, you can do a lot more things with ANTLR, including passing parameter between rules and through all the sub-rules, which helps a lot while making a complex parser, like the parser for C#. Also, the rule re-writing is a classic too. It helps you to format your ideal AST easily.

However, it's really heavy. For a simple project, you probably will never use these functionalities. Javacc is cooler for it.

Ariminum

passing parameters between rules and sub-rules is also supported in javacc – Chewink

Answer 7

I haven't used parser generators in a while, but several years back when I was interested in them, I remember liking SableCC best. It implemented some interesting ideas with respect to object oriented parser generation that may or may not have been picked up by the alternatives.

Maui

We used a modified version of SableCC for the compiler course at my university. It had some really cool features I haven't seen in other places, but I don't know how much of it was our local extensions. – Plug

Answer 8

I wrote a compiler for CAS-language like Maple or MuPAD with SableCC to convert this single language to Maxima (for CAS-Capacity) and LaTeX (to display). SableCC's AST is strict object-oriented and it's easy to extends it to generate diffence languages. If you want to compile a language into more than one others languages, just give it a try.

Infinitude