私は新年のパフォーマンス目標を考えています。コードベース、特に定型文のサイズを縮小するという目標を立てるのは楽しいと思いました。これに対処するために私が思いついたアクションの1つは、Project Lombokを使用して、Beanをできるだけ短くすることです。しかし、私は新しいソフトウェアやアプローチの欠点を見落とす習慣があるので、Stack Overflowコミュニティに頼っています。Lombokが悪い考えである理由を誰かに教えてもらえますか？
23607 次
8 に答える
36
Lombokの制限は、Javaコンパイラと密接に関連しているという事実です。アノテーションプロセッサAPIはコンパイル中にのみ新しいファイルの作成を許可するため（既存のファイルの変更は許可されません）、lombokはそのAPIをJavaコンパイラを変更するためのエントリポイントとして使用します。残念ながら、コンパイラのこれらの変更により、非公開APIが頻繁に使用されます。lombokを使用することは良い考えかもしれませんが、コンパイラーをアップグレードするとコードが破損する可能性があることに注意する必要があります。確率は低いですが、非公開のAPIを使用することは常に不快です。
于 2011-01-04T00:01:01.083 に答える
28
私の意見では、「Java+Lombok」のソースコードはもはやJavaソースコードではありません。ボーランドの会社が何年も前にVCL用のBorlandC++ Builder IDEで作成したものと似ていると思います。彼らは、C ++コードに「プロパティ」を導入し、C ++ではなくなった（ある意味ではC ++ではない）新しいプログラミング言語を効果的に導入しました。 C ++言語の標準）。「Java+Lombok」を使用するソースは、Java言語仕様の意味で有効なソースではありません。さらに、注釈は言語のセマンティクスに影響を与えるようには設計されていないと思います。
于 2018-01-30T21:40:34.593 に答える
23
主な欠点はIDEのサポートです。Lombokは実際には言語の変更ではなく、IDEはJavaしか理解しないため、正しく機能させるにはLombokをサポートするIDEが必要になります。現在のところ、EclipseとIntelliJを含むのはEclipseだけです。eclipseを使用する場合は問題ないかもしれませんが、将来の開発者のためにも決定を下していることを忘れないでください。
コードの一部をgroovyなどのあまり儀式的でない言語に移動することを検討することをお勧めします。ビジネスロジックとモデルの一部をGroovyに移行することに成功し、非常にスムーズに機能します。
于 2011-01-03T23:07:07.780 に答える
22
Lombokのようなものの潜在的な欠点の1つは、セッター/ゲッターが「欠落」していると、ソースツールが結果のオブジェクトの「bean」品質を与える側面を「認識」しない可能性があることです。これらの品質はコンパイルされたクラスでのみ現れるためです。
もう1つの欠点は、ツールチェーン内の「黒魔術」のもう1つの部分であるということです。幸いなことに、それはかなり良性の部分のようであり（私はそれを使用していません）、実行時ではなくコンパイル時に発生するという事実は実際には祝福です（IMHO）。ただし、コードベースにアーティファクトが追加されるため、プロジェクトなしでコードを再利用または共有することはできません。したがって、コンパイルされたクラスファイルは「POJO」である可能性がありますが、ソースコードはPOJOではないと主張します。
これらはどちらも不利な欠点ではなく、楽しみにしていることを知っておくべき側面にすぎません。
于 2011-01-03T23:07:21.803 に答える
5
これはサードパーティのライブラリであり、よく知らない開発者もいます。
IDEは注釈処理をサポートする必要があります（IDEAおよびEclipse用のプラグインがあります）。
上で述べたように、あなたのコードはゲッター/セッターなしになります。ソナー/チェックスタイル違反につながります。
于 2017-11-03T18:05:44.010 に答える
5
私の意見では、Project Lombokの最も明らかなリスクは、lombokを使用することを決定したときに、コードを扱う他のすべての人がlombokを使用することも決定することです。これはすべてのライブラリに当てはまるステートメントですが、Lombokはビルド時の依存関係であり、IDEには何が起こっているのかを把握するためのプラグインが必要であるという点で特別です。それはあなたのコードに触れる理由がある人を意味します。奇妙な振る舞いなどをデバッグしようとしている人は、それを設定する方法とそれがどのように機能するかを知る必要があります。それは少しイライラすることがあります。
于 2020-05-03T17:13:03.093 に答える
4
別の回答でユーザー@Jcsが指摘したように、さらに追加したいと思います。
私たちのプロジェクトでは、マッパークラスの生成に使用されるmapstructを使用しています。コードをコンパイルする前に、mvn generate-sourcesコマンドを使用して、これはmavenプロセッサプラグインを使用してプロセスフェーズで実行されます。
プロジェクトlombokは、コンパイルフェーズでクラスファイルのgetter/setterのバイトコードを追加します。
プロセスフェーズはコンパイルの前に実行されるため、クラスで使用可能なゲッター/セッターがないことがわかります。
複数のコンパイルフェーズを実行するために利用できるいくつかの回避策があります。詳細については、このgitハブチケットを参照してください。
注：私はSpringのSTS ideを使用しており、lombokでサポートされています:)
于 2016-11-09T10:33:20.690 に答える
3
他の応答に追加します。
これを使用しない主な理由はrecord、Java 14の実験的な機能として追加された新しいキーワードです。Java16recordsはプレビューを終了し、ほとんどの場合、プロジェクトLombokを廃止します。
Java 14以降、次のように記述できます。
record Book(String title, String author, String isbn);
これにより、アノテーションなしでコンストラクター、ゲッター/セッター、hashCode、equals、toStringメソッドに自動的にアクセスできます。
于 2021-07-21T14:48:56.557 に答える