Project Lombokが、アノテーションを使用したゲッターやセッターの生成、@ Dataを使用した生成などの単純なJavaBeanの生成など、Javaの煩わしさの一部を支援します。これは、特に、ゲッターで構築および非表示にする必要がある最大7つの異なるフィールドがある50の異なるイベントオブジェクトで、私を本当に助けてくれます。これで約1000行のコードを削除できました。
しかし、長期的には残念な決断になるのではないかと心配しています。私が言及すると、 Flamewarsが##Java Freenodeチャネル内で発生し、コードスニペットを提供すると、ヘルパーの可能性が混乱し、 JavaDocが見つからないことについて不満が出て、将来のコミッターはとにかくそれをすべて削除する可能性があります。ポジティブは本当に楽しいのですが、ネガティブが気になります。
だから：小規模または大規模のプロジェクトでLombokを使用するのは安全ですか？プラスの効果はマイナスの価値がありますか？
今日からロンボクを使い始めました。これまでのところ気に入っていますが、言及されていない欠点の1つは、サポートのリファクタリングでした。
で注釈が付けられたクラスがある場合は@Data、フィールド名に基づいてゲッターとセッターが生成されます。これらのゲッターの1つを別のクラスで使用している場合、フィールドの名前が適切でないと判断すると、それらのゲッターとセッターの使用法が検出されず、古い名前が新しい名前に置き換えられます。
これは、LombokではなくIDEプラグインを介して実行する必要があると思います。
更新（2013年1月22日）
Lombokを3か月間使用した後でも、ほとんどのプロジェクトでこれをお勧めします。しかし、私は上記のような別の欠点を見つけました。
クラスがあり、 2つのメンバーがあり、両方に、sayと、MyCompoundObject.javaの注釈が付いている場合、別のクラスから呼び出すと、それがに委任されているのか、IDE内のソースにジャンプできなくなっているのかを知ることはできません。@DelegatemyWidgetsmyGadgetsmyCompoundObject.getThingies()WidgetGadget
Eclipseの「GenerateDelegateMethods...」を使用すると、同じ機能が提供され、同じように高速で、ソースジャンプが提供されます。欠点は、重要なものから焦点を外す定型コードでソースが乱雑になることです。
UPDATE 2（2013年2月26日）
5か月経っても、まだLombokを使用していますが、他にもいくつかの問題があります。宣言されたゲッターとセッターがないことは、新しいコードに慣れようとしているときに迷惑になることがあります。
たとえば、呼び出されたメソッドgetDynamicCols()が表示されても、それが何であるかわからない場合、このメソッドの目的を判断するためにジャンプするための追加のハードルがいくつかあります。いくつかのハードルはLombokであり、いくつかはLombokスマートプラグインの欠如です。ハードルは次のとおりです。
OutlineビューをフィルタリングしていたMylynを使用しているため、メソッドが表示されなかったことです。 参照の欠如検索。誰が呼び出しているかを確認したい場合は、参照getDynamicCols(args...)を検索できるようにセッターを生成またはコーディングする必要があります。UPDATE 3（2013年3月7日）
Eclipseでさまざまな方法で物事を行う方法を学ぶ。実際には、Lombokで生成されたメソッドに条件付きブレークポイント（BP）を設定できます。ビューを使用してOutline、メソッドを右クリックしてToggle Method Breakpoint。次に、BPを押すと、デバッグVariablesビューを使用して、生成されたメソッドがパラメーターに名前を付けたもの（通常はフィールド名と同じ）を確認し、最後に、Breakpointsビューを使用してBPを右クリックしBreakpoint Properties...、条件を追加することを選択できます。良い。
UPDATE 4（2013年8月16日）
Maven pomでLombokの依存関係を更新する場合、Netbeansはそれを好みません。プロジェクトは引き続きコンパイルされますが、Lombokが作成しているメソッドを確認できないため、ファイルにはコンパイルエラーのフラグが付けられます。Netbeansキャッシュをクリアすると、問題が解決します。Eclipseにあるような「プロジェクトのクリーンアップ」オプションがあるかどうかはわかりません。マイナーな問題ですが、それを知らせたかったのです。
UPDATE 5（2014年1月17日）
Lombokは、Groovy、または少なくともgroovy-eclipse-compiler。コンパイラのバージョンをダウングレードする必要がある場合があります。
MavenGroovyとJava+Lombok
UPDATE 6（2014年6月26日）
警告の言葉。ロンボクはやや中毒性があり、何らかの理由でそれを使用できないプロジェクトに取り組んでいる場合、それはあなたの腹を立てるでしょう。まったく使用しない方がよい場合があります。
アップデート7（2014年7月23日）これは、OPが求めたロンボクを採用することの安全性
に直接対処しているため、少し興味深いアップデートです。
v1.14以降、@Delegateアノテーションは実験的ステータスに降格されました。詳細は彼らのサイト（Lombok Delegate Docs）に文書化されています。
この機能を使用していた場合、バックアウトオプションが制限されます。オプションは次のように表示されます。
@Delegateし、デリゲートコードを生成/ハンドコーディングします。アノテーション内で属性を使用している場合、これは少し難しくなります。@Delegateな注釈を追加し直します。私の知る限り、Delombokには注釈のサブセットを削除するオプションがありません。少なくとも単一のファイルのコンテキストでは、それはすべてか無かです。Delombokフラグを使用してこの機能をリクエストするチケットを開きましたが、近い将来、それを期待していません。
UPDATE 8（2014年10月20日）
それがあなたのオプションである場合、GroovyはLombokと同じ利点のほとんどに加えて、@Delegateを含む他の機能のボートロードを提供します。アイデアを権力者に売り込むのに苦労すると思われる場合は、@CompileStaticまたは@TypeChecked注釈を見て、それがあなたの目的に役立つかどうかを確認してください。実際、Groovy 2.0リリースの主な焦点は、静的な安全性でした。
UPDATE 9（Sep 1 '15）
Lombokはまだ積極的に維持および強化されており、これは採用の安全レベルの前兆です。@Builderアノテーションは、私のお気に入りの新機能の1つです。
UPDATE 10（2015年11月17日）
これはOPの質問に直接関係しているようには見えないかもしれませんが、共有する価値があります。作成する定型コードの量を減らすのに役立つツールを探している場合は、Google Auto、特にAutoValueを確認することもできます。彼らのスライドデッキを見ると、彼らが解決しようとしている問題の可能な解決策としてロンボクをリストアップしてください。彼らがロンボクについて挙げている短所は次のとおりです。
彼らの評価にどれだけ同意するかわかりません。スライドに記載されているAutoValueの短所を考えると、私はLombokに固執します（Groovyがオプションでない場合）。
UPDATE 11（2016年2月8日）SpringRooにも同様の注釈
がある
ことがわかりました。Rooがまだ問題であり、注釈のドキュメントを見つけるのが少し難しいことを知って少し驚いた。取り外しも、デロンボクほど簡単には見えません。ロンボクはより安全な選択のようです。
UPDATE 12（2016年2月17日）
私が現在取り組んでいるプロジェクトにロンボクを安全に持ち込むことが安全である理由を考え出そうとしているときに、追加された金のかけらを見つけましたv1.14-構成システム！これは、チームが安全でないと見なした、または望ましくないと見なした特定の機能を許可しないようにプロジェクトを構成できることを意味します。さらに良いことに、さまざまな設定でディレクトリ固有の構成を作成することもできます。これは素晴らしいです。
UPDATE 13（2016年10月4日）
この種のことが重要な場合、OliverGierkeはLombokをSpringDataRestに追加しても安全だと感じました。
UPDATE 14（Sep 26 '17） OPsの質問に対するコメントで@gavenkoa
が
指摘しているように、 JDK9コンパイラのサポートはまだ利用できません（問題＃985）。また、ロンボクチームが回避するのは簡単な修正ではないようです。
UPDATE 15（2018年3月26日）
Lombokの変更ログには、v1.16.20の時点で、 ＃985がまだ開いていても、「JDK1.9でのlombokのコンパイルが可能になりました」と示されています。
ただし、JDK9に対応するための変更には、いくつかの重大な変更が必要でした。設定のデフォルトの変更にすべて分離されています。彼らが重大な変更を導入したことは少し心配ですが、バージョンは「インクリメンタル」バージョン番号（v1.16.18からv1.16.20に移行）のみを上げました。この投稿は安全性に関するものだったのでyarn/npm、最新のインクリメンタルバージョンに自動的にアップグレードする同様のビルドシステムがある場合は、失礼な目覚めに陥る可能性があります。
UPDATE 16（19年1月9日）
JDK9の問題は解決され、LombokはJDK10、さらにはJDK11でも動作するようです。
安全性の観点から気付いたのは、v1.18.2からv1.18.4への変更ログに2つの項目がBREAKING CHANGE！？semverの「パッチ」アップデートで重大な変更がどのように発生するかわかりません。パッチバージョンを自動更新するツールを使用する場合、問題になる可能性があります。
UPDATE 17（21年3月17日）
Lombok開発者とOpenJDK開発者の間でJDK16の周りにいくつかのドラマが展開されてい ます。JDK開発者は、LombokがJDKチームが閉じたいループホールを介して未公開のJDK内部を利用していると主張していますが、さまざまな理由で意図的に開いたままにしています。
彼らは（ロンボクの安全性について）懸念を次のように述べています。
内部へのすべてのアクセスは、クライアントアプリケーションが明示的に許可し、これに伴うメンテナンス（またはセキュリティ）の問題を故意に引き受けていることを認める限り、以前と同じように利用できます。
LombokはOpenJDKをだましていると思うかもしれませんが、彼らがしているのは、自分のユーザーをだまそうとしていることを発表することだけです。
ロンボクがJDKのセキュリティ制限に関するこれ以上の創造的な解決策を見つけることができなくなる日がすぐに来るかもしれません。たとえそうだとしても、プロジェクトでLombokを使用することの安全性に疑問があるかもしれません。
Project Lombokは、提案された新しいプロジェクトに重要な技術的利点をもたらすことをすでに決定しているようです。（最初から明確にするために、私はProject Lombokについて特に意見はありません。）
一部のプロジェクト（オープンソースまたはその他の方法）でProject Lombok（またはその他のゲームを変えるテクノロジー）を使用する前に、プロジェクトの利害関係者がこれに同意していることを確認する必要があります。これには、開発者、および重要なユーザー（公式または非公式のスポンサーなど）が含まれます。
あなたはこれらの潜在的な問題に言及します：
私が言及すると、Flamewarsは##JavaFreenodeチャネルで発生します。
簡単。炎上戦争を無視する/参加しない、または単にロンボクに言及することを控える。
コードスニペットを提供すると、ヘルパーの可能性が混乱します。
プロジェクト戦略がロンボクを使用することである場合、可能なヘルパーはそれに慣れる必要があります。
人々はJavaDocの欠落について不平を言うでしょう、
それが彼らの問題です。組織のソースコード/ドキュメントルールをサードパーティのオープンソースソフトウェアに厳密に適用しようとする人は誰もいません。プロジェクトチームは、使用されているテクノロジに適したプロジェクトのソースコード/ドキュメントの標準を自由に設定できる必要があります。
（フォローアップ-Lombok開発者は、合成されたgetterおよびsetterメソッドのjavadocコメントを生成しないことが問題であることを認識しています。これがプロジェクトの主要な問題である場合、1つの代替手段は、これに対処するLombokパッチを作成して送信することです。 ）。
そして将来のコミッターはとにかくそれをすべて削除するかもしれません。
それはオンではありません！合意されたプロジェクト戦略がLombokを使用することである場合、コードを無償でde-Lombokしたコミッターは非難され、必要に応じてコミット権が取り消されます。
もちろん、これは、開発者を含む利害関係者からの賛同を得ていることを前提としています。そして、それはあなたがあなたの原因を議論する準備ができていて、避けられない反対意見を適切に処理することを前提としています。
先に進み、Lombokを使用します。必要に応じて、後でコードを「delombok」できますhttp://projectlombok.org/features/delombok.html
個人的に（したがって主観的に）、Lombokを使用すると、ハッシュコードや等式などの複雑なメソッドのIDE /独自の実装と比較して、達成しようとしていることについてコードがより表現力豊かになることがわかりました。
使用する場合
@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })
IDE /独自の実装よりも、Equals＆HashCodeの一貫性を維持し、評価されるフィールドを追跡する方がはるかに簡単です。これは、フィールドを定期的に追加/削除している場合に特に当てはまります。
同じことが、@ToString含まれる/除外されるフィールド、ゲッターの使用法またはフィールドアクセス、および呼び出すかどうかに関する望ましい動作を明確に伝える注釈とそのパラメーターにも当てはまりますsuper.toString()。
@Getterまた、クラス全体にor （およびオプションで発散メソッドをオーバーライドする）の注釈を付ける@Setter(AccessLevel.NONE)ことで、フィールドで使用できるメソッドがすぐにわかります。
メリットはどんどん増えていきます。
私の考えでは、コードを削減することではなく、Javadocや実装からコードを理解する必要はなく、達成したいことを明確に伝えることです。削減されたコードにより、発散メソッドの実装を簡単に見つけることができます。
私はロンボクについてのいくつかの意見を読みました、そして実際に私はいくつかのプロジェクトでそれを使用しています。
さて、ロンボクとの最初の接触で、私は悪い印象を持っていました。数週間後、私はそれが好きになり始めました。しかし、数ヶ月後、私はそれを使用して多くの小さな問題を理解しました。ですから、ロンボクについての私の最終的な印象はそれほど前向きではありません。
このように考える私の理由：
@Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor、クラスを実際に公開する必要があるメソッドを考えずに、アノテーションブロックをコピーして貼り付けるだけです。@Builderはコンストラクターや静的コンストラクターメソッドの代わりに使用することを好みます。時々彼らはlombokBuilder内にBuilderを作成しようとし、のような奇妙な状況を作成しMyClass.builder().name("Name").build().create()ます。@AllArgsConstructorしていて、コンストラクターにもう1つのパラメーターを追加する必要がある場合、IDEは、クラスをインスタンス化するすべての場所（ほとんどの場合テスト）にこの追加パラメーターを追加するのに役立ちません。別の回答が言ったように、Javaの冗長性に腹を立て、Lombokを使用してそれに対処する場合は、Kotlinを試してください。
ロンボクは素晴らしいですが...
Lombokは、新しいソースファイルを生成しないという点で、注釈処理のルールに違反しています。これは、ゲッター/セッターまたは他の何かが存在することを期待している場合、別の注釈プロセッサーで使用できないことを意味します。
注釈処理は一連のラウンドで実行されます。各ラウンドで、それぞれが実行する順番を取得します。ラウンドの完了後に新しいJavaファイルが見つかった場合は、別のラウンドが開始されます。このように、注釈プロセッサが新しいファイルを生成するだけであれば、注釈プロセッサの順序は重要ではありません。lombokは新しいファイルを生成しないため、新しいラウンドは開始されず、lombokコードに依存する一部のAPは期待どおりに実行されません。これは、mapstructを使用している間、私にとって大きな苦痛の原因でした。また、ログ内の行番号が破壊されるため、デロンボッキングは有用なオプションではありません。
最終的に、lombokとmapstructの両方で動作するようにビルドスクリプトをハッキングしました。しかし、少なくともこのプロジェクトでは、それがいかにハッキーであるかという理由で、lombokを削除したいと思います。私は他のものでいつもロンボクを使います。特にmapstruct+lombokに更新します。現在、2つのライブラリはそのままで相互に機能します。ただし、他の注釈プロセッサでも問題は解決しません。
長期的なメンテナンスのリスクもあります。まず、Lombokが実際にどのように機能するかについて読むことをお勧めします。たとえば、ここにある開発者からの回答です。
公式サイトには、Reinier Zwitserlootからのこの引用を含む、欠点のリストも含まれています。
それは完全なハックです。非公開APIを使用します。思いがけないキャスト（javacで実行されているアノテーションプロセッサがJavacAnnotationProcessorのインスタンスを取得することを知っています。これはAnnotationProcessor（インターフェイス）の内部実装であり、ライブASTで取得するために使用されるいくつかの追加メソッドがあります） 。
Eclipseの場合、それは間違いなくさらに悪いです（そしてさらに堅牢です）-Javaエージェントを使用して、Eclipseの文法とパーサークラスにコードを挿入します。これはもちろん完全に非公開のAPIであり、完全に立ち入り禁止です。
lombokが標準APIで行うことを実行できれば、私はそのように実行できたはずですが、実行できません。それでも、その価値のために、私はjava1.6で実行されるeclipsev3.5用のeclipseプラグインを開発しました。変更を加えることなく、java1.5で実行されるeclipsev3.4でも機能するため、完全に壊れやすいわけではありません。
要約すると、Lombokは開発時間を節約する可能性がありますが、下位互換性のないjavacアップデート（脆弱性の軽減など）がある場合、開発者がそれらの使用法を更新するためにスクランブルしている間、Lombokは古いバージョンのJavaでスタックする可能性があります内部API。これが深刻なリスクであるかどうかは、明らかにプロジェクトによって異なります。
私はほぼすべてのプロジェクトでLombokを1年間使用しましたが、残念ながらそれを削除しました。当初は非常にクリーンな開発方法でしたが、新しいチームメンバーの開発環境を設定することは非常に簡単で簡単ではありません。それが頭痛になったとき、私はそれを取り除いた。しかし、それは良い仕事であり、セットアップにはもう少し簡単なものが必要です。
私は遅れていることは知っていますが、その誘惑に抵抗することはできません。ロンボクが好きな人は誰でもスカラを見る必要があります。ロンボクで見つけた多くの良いアイデアは、Scala言語の一部です。
あなたの質問について：Scalaよりも開発者にLombokを試してもらう方が間違いなく簡単です。試してみて、気に入ったらScalaを試してみてください。
免責事項と同じように：私もJavaが好きです！
チームにプロジェクトを見せた時の熱意は高かったので、チームの反応を恐れてはいけないと思います。
ROIに関しては、簡単に統合でき、基本的な形式でコードを変更する必要はありません。（クラスに単一のアノテーションを追加するだけです）
最後に、気が変わった場合は、unlombokを実行するか、IDEにこれらのセッター、ゲッター、およびctorを作成させることができます（pojoがどれほど明確になるかを確認したら、誰も要求しないと思います）。
Lombokについての私の見解は、それが単にbolilerplateJavaコードを書くためのショートカットを提供するということです。
bolilerplate Javaコードを記述するためのショートカットの使用に関しては、IDEが提供するそのような機能に依存します。Eclipseの場合と同様に、[ソース]>[ゲッターとセッターの生成]に移動してゲッターとセッターを生成できます。
私はこれについてロンボクのようなライブラリに依存しません：
@Getterます@Setter。Javaの代替構文を学ぶのではなく、Lombokのような構文をネイティブに提供する他の言語に切り替えます。全体として、私はLombokでJavaを「スパイスアップ」したくありません。
ロンボクを使用したかったの@ToStringですが、IntellijIDEAでのプロジェクトの再構築時にランダムなコンパイルエラーにすぐに直面しました。インクリメンタルコンパイルが正常に完了する前に、コンパイルを数回押す必要がありました。
jdk1.6.0_39および1.6.0_45でlombokプラグインを使用せずにIntellijIDEA12.1.6および13.0でlombok1.12.2および0.9.3の両方を試しました。
デロンボクされたソースから生成されたメソッドを手動でコピーし、より良い時期までlombokを保留にする必要がありました。
アップデート
この問題は、並列コンパイルが有効になっている場合にのみ発生します。
問題を提出しました： https ：//github.com/rzwitserloot/lombok/issues/648
アップデート
mplushnikovは2016年1月30日にコメントしました：
Intellijの新しいバージョンでは、このような問題は発生していません。ここで閉めることができると思います。
アップデート
可能であれば、Java+LombokからKotlinに切り替えることを強くお勧めします。Lombokが回避しようとするすべてのJavaの問題がゼロから解決されたため、
LombokとJacksonCSVで問題が発生しました。オブジェクト（Java Bean）をCSVファイルにマーシャリングし、列が重複している場合、Lombokの@Dataアノテーションを削除すると、マーシャライズは正常に機能しました。
私はそれをお勧めしません。以前はそれを使用していましたが、NetBeans 7.4を使用すると、コードが混乱していました。プロジェクト内のすべてのファイルでロンボクを削除する必要があります。デロンボクがありますが、どうすればそれが私のコードを台無しにしないことを確認できますか。ロンボクを削除して通常のJavaスタイルに戻すためだけに何日も費やす必要があります。辛すぎる…
私はまだロンボクを使ってみませんでした-それは私のリストの次ですが、Java 8がそれに対して重大な問題を引き起こしたように聞こえ、1週間前の時点でまだ修復作業が進行中です。そのための私のソースはhttps://code.google.com/p/projectlombok/issues/detail?id=451です。