java - 注釈プロセッサとバイトコード生成

Question

バイトコード生成に関する注釈処理の相対的なメリットとデメリットは何ですか(例: ASMを使用)? 実装の難しさは別として、なぜ他のものよりもどちらを好むのですか?

コメンターが尋ねたので、抽象ゲッター/セッターメソッドの実装を自動的に生成しようとしていますが、より一般的な回答が欲しいです. ゲッターとセッターを生成するためのより良い方法は何かを尋ねているのではありません。

Answer 1

一部のバイトコード ジェネレーター ライブラリには、getter/setter 変数の簡単な作成がサポートされているため、作業が大幅に簡素化されます。ライブラリ クラスをインポートして Java コードを記述するだけです。一部のフレームワークは、フィールドの単純な注釈に基づいて、getter と setter を (他の多くのものと共に) 自動的に生成することさえできます。

一方、バイトコード生成は一般に、新しいクラスがコンパイルされるため、実行時のパフォーマンスに影響を与えますが、生成されたクラス ファイルをキャッシュすることで軽減できます。

注釈処理に関する私の経験は、それほど楽しいものではありませんでした。通常、アノテーション プロセッサが実行されるように、ビルド システムを構成または変更する必要があります。さらに、ソースコードファイルを大幅に変更したい場合、アノテーションプロセッサのコーディングは非常に不快になる可能性があり、バイトコード生成と同じフレームワーク/ライブラリの多様性にはほど遠いようです。

正直なところ、私の個人的な好みは、可能であればJava 7 のメソッド ハンドルを使用することです。

編集：

注釈処理 API の主な問題は、(私の知る限り)コンパイル時のコードの変更をサポートしていないことです。推奨されるアプローチは、独立したデコレータ クラスの生成のようです。確かに、 Apache Velocityなどを使用すれば比較的簡単ですが、最終的な結果はほぼ同じではありません。

元のソース ファイルを処理してメソッドを追加し、再コンパイルするハックがいくつかありますが、ソース ファイルのパスを取得することさえほとんど不可能です。通常、プロジェクトの構造に関するさまざまな仮定が行われており、多くの当て推量が関係しています。さらに、注釈プロセッサは、基本的に、処理されたソース ファイル用に別のソース ツリーを維持します。

Project Lombok (前に言い忘れたとは信じられません) は、さまざまな色の魔法をたくさん使って、注釈処理 API を活用して、より使いやすいものにしています。それはあなたが必要とするものである可能性が非常に高いです...

Answer 2

最善の方法は、IDE のアクセラレータを使用してゲッターとセッターを生成することです。そうすれば、それらはソースコードに存在します。これにより、コードが読みやすくなり、デバッガーで発生する可能性のある問題を回避できます。

ゲッターとセッターを作成するのは少し面倒ですが、それを回避するために複雑さ (および潜在的な落とし穴) を追加する価値はありません。(そして、本当に面倒なら、助けてくれる「コードモンキー」が必要だと上司を説得してください。)