meta data for this page
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
| key_differences [2020/02/09 23:14] – revusky | key_differences [2021/02/08 18:09] – ↷ Links adapted because of a move operation 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 17: | Line 17: | ||
| JavaCC 21 introduces a new statement called **INJECT** that allows you to " | JavaCC 21 introduces a new statement called **INJECT** that allows you to " | ||
| - | ===== JavaCC is being actively developed | + | ===== Streamlined Syntax |
| - | JavaCC 21 now supports the Java language up to Java 8, including Lambda expressions. Since the Java.freecc | + | 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 now supports the full Java language up through | ||