懸念事項は、ドキュメント/学習可能性、Eclipse統合、ツール、コミュニティサポートおよびパフォーマンスです(おおよその順序で)。
除外すべきではない代替策がいくつかあります。
一般的に、コードジェネレーターの年月は終わったような印象を受けます。私があなたなら、Scalaのパーサーコンビネーターツールキットを使用します。基本的に、IDE Scalaをサポートし、このパーサーコンビネーターフレームワークも「サポート」します。パフォーマンスは良好です、AFAICT。
ところで、ANTLRはEclipseプラグインとしてかなりまともなIDEサポートを持っています(しかし、おそらくIntelliJにも何かがある-覚えていません。)したがって、もしあなたが古典的なアプローチを選ぶなら言語外でレキシカルアナライザーとパーサーを定義する場合、ANTLRを選択する必要があると思います。これには、Java開発者の間で最大のマインドシェアがあり、ツールサポートがあり、すばらしいANTLRの作者による本ですが、他のどのツールキットもそれを主張できるとは思いません。
あなたが言及した懸念に関して、私はJavaCCがより良い選択であることを提案します。 Java開発者が学ぶのはより速くて簡単です(構文は通常のJavaに非常に似ています)、ドキュメントは包括的で、Eclipse統合は適切です。
ANTLRはより完全な機能を備えています。字句解析、解析、AST、ツリー変換、コード生成など、ボックスコンパイラコンパイラよりもはるかに優れています。
JavaCCの場合、これはコンパイラー・コンパイラーよりもパーサー・ジェネレーターです。 ASTサポートは、JJTreeと呼ばれる別のlibを通じて提供されます。
最初の概算では、実際にあなたにとって本当に重要なことは、その表記法があなたの目にとってどれほど便利で直感的であるかです。
そうは言っても、私はANTLRとJavaCCを使用してプロジェクトを実行しましたが、ANTLRはほとんどの場合、非常に重いことがわかりました。
ANTLRのJavaCCに対する具体的な利点は、Java以外の言語用のジェネレーターがあることです。これにより、言語を他の場所に簡単に移植できるようになります。
私は上記の2番目のjamesh。
ANTLRはより完全な機能を備えています。字句解析、解析、AST、ツリー変換、コード生成など、ボックスコンパイラコンパイラよりもはるかに優れています。
JavaCCの場合、これはコンパイラー・コンパイラーよりもパーサー・ジェネレーターです。 ASTサポートは、JJTreeと呼ばれる別のlibを通じて提供されます。
私の個人的な経験から、ANTLRを使用すると、ルール間やすべてのサブルールを介してパラメーターを渡すなど、C#のパーサーのような複雑なパーサーを作成するのに非常に役立ちます。また、ルールの書き換えも古典的です。理想的なAST=を簡単にフォーマットするのに役立ちます。
しかし、それは本当に重いです。単純なプロジェクトの場合、これらの機能を使用することはおそらくないでしょう。 Javaccはそれに対してよりクールです。
パーサージェネレーターはしばらく使用していませんが、数年前から興味があったので、 SableCC を気に入ったのを覚えています。オブジェクト指向のパーサーの生成に関して、いくつかの興味深いアイデアを実装しました。これらは、代替案では取り上げられていない場合もあります。
MapleやMuPADなどのCAS言語用のコンパイラーをSableCCで作成して、この単一の言語をMaxima(CAS-Capacity用)とLaTeX(表示用)に変換しました。 SableCCのASTは厳密なオブジェクト指向であり、拡張してディファレンス言語を生成するのは簡単です。言語を他の複数の言語にコンパイルしたい場合は、試してみてください。