meta data for this page
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
key_differences [2020/04/08 14:27] – [JavaCC is being actively developed] revusky | key_differences [2020/12/12 23:28] – [JavaCC 21 is being actively developed] revusky | ||
---|---|---|---|
Line 3: | Line 3: | ||
From the end user's point of view, the most important difference is that JavaCC 21 has undergone quite a bit of re-design to make it much more usable "out of the box" than the legacy JavaCC. One of the most basic (and obvious) things that JavaCC 21 provides is the [[INCLUDE]] statement. With legacy JavaCC, the only way to reuse commonly used constructs across different grammars was via the classic copy-paste // | From the end user's point of view, the most important difference is that JavaCC 21 has undergone quite a bit of re-design to make it much more usable "out of the box" than the legacy JavaCC. One of the most basic (and obvious) things that JavaCC 21 provides is the [[INCLUDE]] statement. With legacy JavaCC, the only way to reuse commonly used constructs across different grammars was via the classic copy-paste // | ||
- | There has been an effort to clean up the set of configuration options. In general, the philosophy of JavaCC 21 is to make configuration options largely unnecessary, | + | There has been an effort to clean up the set of configuration options. In general, the philosophy of JavaCC 21 is to make configuration options largely unnecessary, |
It seems quite clear that building an AST [[Abstract Syntax Tree]] is the most typical use case for this sort of tool. So, there has been a heavy focus on making the whole thing much simpler. In legacy JavaCC, generating a parser that builds an AST is actually a rather baroque build process. You write a grammar with special " | It seems quite clear that building an AST [[Abstract Syntax Tree]] is the most typical use case for this sort of tool. So, there has been a heavy focus on making the whole thing much simpler. In legacy JavaCC, generating a parser that builds an AST is actually a rather baroque build process. You write a grammar with special " | ||
Line 16: | Line 16: | ||
JavaCC 21 introduces a new statement called **INJECT** that allows you to " | JavaCC 21 introduces a new statement called **INJECT** that allows you to " | ||
+ | |||
+ | ===== Streamlined Syntax ===== | ||
+ | |||
+ | JavaCC 21 incorporates an [[new syntax summary|alternative streamlined syntax]] that should be quite a bit more pleasant to write and easier to read. | ||
+ | |||
+ | The difference is frequently dramatic. Where the legacy tool required you to write things like: | ||
+ | |||
+ | < | ||
+ | LOOKAHEAD (Foo() Bar()) Foo() Bar() Baz() | ||
+ | </ | ||
+ | |||
+ | in JavaCC 21 you could express the above as: | ||
+ | |||
+ | < | ||
+ | Foo Bar =>|| Baz | ||
+ | </ | ||
+ | |||
+ | ===== More powerful lookahead ===== | ||
+ | |||
+ | Perhaps most importantly, | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The new [[up to here]] construct should eliminate the need to write more verbose and error-prone numerical and syntactic lookahead constructs. | ||
+ | |||
+ | |||
+ | |||
===== JavaCC 21 is being actively developed ===== | ===== JavaCC 21 is being actively developed ===== | ||
- | JavaCC 21 now supports the full Java language up through Java 13. Since the [[Java.javacc|https:// | + | JavaCC 21 now supports the full Java language up through Java 15. Since the [[https:// |