I have been doing language parsing and generation in C for several years: English, French, Japanese, Chinese, Korean. Still, I hoped to learn something new from CGIA for Java. I was disappointed. I think the book misdirects the reader away from more effective solutions into less productive paths.
The book suffers from two problems. (1) the regular expression technology proposed is inappropriate (2) the exercises provided are not rich enough to be useful.
I have no objection to scripting languages. I have happily used bash, gawk, python/Jpython and php. I avoided perl because I was struck by its lack of readability and writability. Ruby is no better and no worse than many scripting languages, but the documentation and error messages leave very much to be desired. CGIA offers almost nothing in the way of real help with the language. It took me some time to figure out how to install the libraries properly and debugging was a nightmare! Ruby's regular expression language is yet another variation in the regex language Babel. This is not something I would foist on developers in my organization. Especially when there are much better alternatives.
For years I have been using lex (flex actually) in C for code generation and human language processing. (I have never had much use for YACC/Bison.) When I switched to Java, I found an excellent flex equivalent called JFlex ([...]
JFlex.jar is around 240K. The regular expression language for JFlex is extremely close to that of lex and gawk. It is much more readable and modular than that of ruby, perl, etc. Your Java programmers and maintainers need not learn a new language or download/install/configure an additional 28 MB of libraries. Even better, they can use JFlex in runtime production code, since it produces compiled FSA's which are orders of magnitude faster than an interpreted regex processor like ruby.
Additionally, you can get with lex/flex/JFlex full grammars for C++ and Java, not the superficial variable reader that came with CGIA. And the debugging mode, while not perfect, is quite usable. (There are commercial visual tools for debugging flex grammars, if you need and can afford them.)
From the code point of view, I found nothing usable in CGIA. In my judgment most of the examples were more suited to the classroom than to work, and the solutions presented were often not competitive with alternatives. On the theory/fundamentals side the book does not contribute much to the the understanding of language parsing or generation issues.
The arguments for using code generation are cogent. But if you want to use a more useful, popular, constantly evolving (but equally poorly documented) code generation system, go for XDoclet.
My recommendation: skip CGIA. Spend your time and money learning flex/JFlex for parsing and XDoclet for generating and you will be much better off. If you want theory, sink your teeth into something like the "Dragon" classic (Aho & Ullman).