Project Lombokを使用しても安全ですか？
あなたが知らない場合 Project Lombokアノテーションを使ってゲッターやセッターを生成する そして 単純なJavaBeanを生成する） @Data を使用します。特に、ゲッターで構築したり隠したりする必要のある最大7つの異なるフィールドがある50の異なるイベントオブジェクトでは、私にとって非常に役立ちます。これで1000行近くのコードを削除できました。
しかし、長期的には残念な決断になると私は心配しています。私が言及すると、Flamewarsは##Java Freenodeチャンネルで発生します。コードスニペットを使用するとヘルパーが混乱する可能性があります 人々はJavaDocがないことに文句を言うでしょう 私は本当にポジティブを楽しむでしょうが、私はネガティブについて心配しています。
それでは、Lombokを大小のプロジェクトで使用しても安全ですか。プラスの効果はマイナスの価値がありますか？
Project Lombokが提案された新しいプロジェクトに大きな技術的優位性をもたらすことをすでに決定しているようです。 （最初から明確にするために、私はプロジェクトロンボクについては特に関係ありません。）
あるプロジェクト（オープンソースまたは他の賢い方法）でProject Lombok（またはその他のゲームを変える技術）を使用する前に、プロジェクトの利害関係者がこれに同意することを確認する必要があります。これには、開発者、および重要なユーザー（正式または非公式のスポンサーなど）が含まれます。
あなたはこれらの潜在的な問題に言及します：
言及すると、Flamewarsは## Java Freenodeチャンネルで発生します。
簡単です。フレームワークを無視する、または参加しない、または単にロンボクに言及することを控える。
コードスニペットを提供することは、可能性のあるヘルパーを混乱させるでしょう、
プロジェクト戦略がLombokを使用することであるならば、可能なヘルパーはそれに慣れる必要があるでしょう。
人々はJavaDocの欠如について文句を言うでしょう、
それが彼らの問題です。正しい考えでは、組織のソースコードやドキュメントの規則を第三者のオープンソースソフトウェアに厳密に適用しようとする人はいません。プロジェクトチームは、使用されているテクノロジに適したプロジェクトソースコード/ドキュメント標準を自由に設定できます。
（FOLLOWUP - Lombokの開発者は、合成されたgetterメソッドおよびsetterメソッドに対してjavadocコメントを生成しないことが問題であることを認識しています。これがあなたのプロジェクトにとって大きな問題である場合そしてこれに対処するためにLombokパッチを提出してください。）
とにかく将来のコミッタはそれをすべて削除するかもしれません。
そうじゃない！合意されたプロジェクト戦略がLombokを使用することである場合、コードを無償でde-Lombokから削除したコミッターは懲戒されるべきであり、もし必要なら彼らのコミット権を撤回させるべきです。
もちろん、これはあなたが開発者を含むステークホルダーからバイインしていることを前提としています。そしてそれは、あなたがあなたの原因を議論し、避けられない反対意見を適切に処理する準備ができていることを前提としています。
今日Lombokの使用を開始しました。これまでのところは気に入っていますが、言及されていなかった欠点の1つは、リファクタリングのサポートです。
@Dataアノテーションが付けられたクラスがある場合、フィールド名に基づいてゲッターとセッターを生成します。これらのゲッターの1つを別のクラスで使用する場合、フィールドの名前が不適切であると判断すると、それらのゲッターとセッターの使用法が見つからず、古い名前が新しい名前に置き換えられます。
これは、LombokではなくIDEプラグインを介して行う必要があると思います。
更新（13年1月22日）
Lombokを3か月使用した後、ほとんどのプロジェクトに引き続きお勧めします。しかし、上に挙げたものと同様の別の欠点を見つけました。
クラスがある場合、別のクラスからmyCompoundObject.getThingies()を呼び出すときに、MyCompoundObject.Javaアノテーションが付いた2つのメンバーを持つ@Delegate、たとえばmyWidgetsとmyGadgetsと言う、IDE内のソースにジャンプできないため、WidgetまたはGadgetに委任されているかどうかを知ることはできません。
Eclipseの「デリゲートメソッドの生成...」を使用すると、同じ機能が提供され、同じくらい迅速で、ソースジャンプが提供されます。欠点は、重要なものから焦点を外す定型コードでソースを混乱させることです。
更新2（13年2月26日）
5か月後、私たちはまだLombokを使用していますが、他にも迷惑があります。宣言されたゲッターとセッターの欠如は、新しいコードに慣れようとしているときに迷惑になることがあります。
たとえば、getDynamicCols()というメソッドが表示されているが、それが何であるかわからない場合、このメソッドの目的を判断するためにいくつかの追加のハードルがあります。ハードルの一部はLombokで、一部はLombokスマートプラグインの欠如です。ハードルが含まれます：
- JavaDocsの欠如。フィールドをjavadocにした場合、getterおよびsetterがLombokコンパイル手順を通じてそのjavadocを継承することを望みます。
- メソッド定義にジャンプすると、クラスにジャンプしますが、ゲッターを生成したプロパティにはジャンプしません。これはプラグインの問題です。
- メソッドを生成またはコーディングしない限り、ゲッター/セッターにブレークポイントを設定できないことは明らかです。
- 注：この参照検索は、私が最初に思ったように問題ではありません。ただし、アウトラインビューを有効にするパースペクティブを使用する必要があります。ほとんどの開発者にとっては問題ありません。私の問題は、
OutlineビューをフィルタリングしているMylynを使用しているため、メソッドが表示されないことでした。 参照検索の欠如。誰がgetDynamicCols(args...)を呼び出しているかを知りたい場合は、参照を検索できるようにセッターを生成またはコーディングする必要があります。
更新3（13年3月7日）
Eclipseで物事を行うさまざまな方法を使用することを学ぶと思います。 Lombokで生成されたメソッドに条件付きブレークポイント（BP）を実際に設定できます。 Outlineビューを使用して、Toggle Method Breakpointへのメソッドを右クリックできます。次に、BPにアクセスすると、デバッグVariablesビューを使用して、生成されたメソッドがパラメーターの名前（通常はフィールド名と同じ）を確認し、最後にBreakpointsビューを使用して、 BPをクリックし、Breakpoint Properties...を選択して条件を追加します。いいね.
更新4（13年8月16日）
Netbeansは、Maven pomでLombok依存関係を更新するとき、それを好まない。プロジェクトはまだコンパイルされますが、Lombokが作成しているメソッドが表示されないため、コンパイルエラーが発生したファイルにフラグが付けられます。 Netbeansキャッシュをクリアすると、問題が解決します。 Eclipseにあるような「Clean Project」オプションがあるかどうかはわかりません。マイナーな問題ですが、それを知らせたいと思いました。
更新5（14年1月17日）
Lombokは常にGroovyでNiceをプレイするわけではなく、少なくともgroovy-Eclipse-compilerをプレイするわけでもありません。コンパイラのバージョンをダウングレードする必要がある場合があります。 Maven GroovyおよびJava + Lombok
更新6（14年6月26日）
警告の言葉。 Lombokはやや中毒性があり、何らかの理由で使用できないプロジェクトに取り組んでいる場合、それはあなたを怒らせます。まったく使わないほうがいいかもしれません。
更新7（14年7月23日）
これは、OPが尋ねたLombokの採用のsafetyに直接対処するため、少し興味深いアップデートです。
V1.14の時点で、@Delegateアノテーションは実験的ステータスに降格されました。詳細はサイトに文書化されています（ Lombok Delegate Docs ）。
問題は、この機能を使用している場合、バックアウトオプションが制限されることです。オプションは次のように表示されます。
@Delegate注釈を手動で削除し、デリゲートコードを生成/ハンドコードします。アノテーション内で属性を使用していた場合、これは少し難しくなります。@Delegate注釈を持つファイルを削除し、必要に応じて注釈を追加し直します。- Lombokを更新したり、フォークを維持したりしないでください（または、体験的な機能を使用して共存してください）。
- プロジェクト全体をDelombokし、Lombokの使用を停止します。
私が知る限り、 Delombokには注釈のサブセットを削除するオプションはありません ;少なくとも1つのファイルのコンテキストについては、すべてかまったくありません。 この機能を要求するチケット をDelombokフラグ付きで開きましたが、近い将来にはそうなるとは思いません。
更新8（14年10月20日）
Groovyがオプションの場合、Lombokとほぼ同じ利点に加えて、 @ Delegate を含む他の機能のボート負荷を提供します。アイデアを権力者に売るのに苦労すると思うなら、@CompileStaticまたは@TypeCheckedアノテーションを見て、それがあなたの大義に役立つかどうか確かめてください。実際、 Groovy 2.0リリースの主な焦点は静的安全性でした 。
更新9（15年9月1日）
Lombokはまだ 積極的に保守および強化されています であり、これは採用の安全性レベルに適しています。 @ Builder アノテーションは、私のお気に入りの新機能の1つです。
更新10（15年11月17日）
これは、OPの質問に直接関連していないように見えるかもしれませんが、共有する価値があります。書く定型コードの量を減らすのに役立つツールを探している場合は、 Google Auto -特に AutoValue も確認できます。 slide deck を見ると、彼らが解決しようとしている問題の可能な解決策としてリストLombokがあります。 Lombokのリストには次のような短所があります。
- 挿入されたコードは表示されません（生成されたメソッドを「見る」ことはできません）[注-実際にはできますが、逆コンパイラが必要です]
- コンパイラーのハックは非標準であり、脆弱です
- 「私たちの見解では、あなたのコードはもはやJavaではありません」
私は彼らの評価にどれだけ同意するかわかりません。スライドに文書化されているAutoValueの短所を考えると、Lombokに固執します（Groovyがオプションでない場合）。
更新11（16年2月8日）
私は Spring Roo にいくつかの 類似の注釈 があることを発見しました。 Rooがまだ物であり、注釈のドキュメントを見つけるのが少し荒いことを知って少し驚きました。削除もde-lombokほど簡単ではありません。ロンボクはより安全な選択のようです。
更新12（16年2月17日）
私が現在取り組んでいるプロジェクトにロンボクを持ち込むことが安全である理由を正当化しようと試みている間に、v1.14で追加された金を見つけました-- 構成システム ！これは、チームが安全でないまたは望ましくないと判断する特定の機能を禁止するようにプロジェクトを構成できることを意味します。さらに良いことに、異なる設定でディレクトリ固有の設定を作成することもできます。これは素晴らしいです。
更新13（16年10月4日）
この種のことが重要な場合、 Oliver Gierke は安全だと感じました Spring Data RestにLombokを追加 。
更新14（17年9月26日）
OPの質問に対するコメントの @ gavenkoa で指摘されているように、 JDK9コンパイラのサポートはまだ利用できません （問題＃985）。また、Lombokチームが簡単に回避することはできないようです。
更新15（18年3月26日）
Lombokの変更ログには、v1.16.20の時点で「 JDK1.9でのLombokのコンパイルが可能になりました＃985 はまだ開いていますが、.
ただし、JDK9に対応するための変更には、いくつかの重大な変更が必要でした。すべてが設定のデフォルトの変更に対して隔離されています。重大な変更が導入されたことは少し懸念されますが、バージョンは「増分」バージョン番号（v1.16.18からv1.16.20に変更）だけを増やしました。この投稿は安全性に関するものであるため、自動的に最新のインクリメンタルバージョンにアップグレードされたyarn/npmのようなビルドシステムがあれば、失礼な目覚めに陥る可能性があります。
更新16（19年1月9日）
JDK9の問題は解決された のようで、LombokはJDK10で動作します。
安全性の観点から気づいたことの1つは、v1.18.2からv1.18.4への変更ログに2つの項目がBREAKING CHANGE !?としてリストされているという事実です。 semverの「パッチ」アップデートでどのように重大な変更が発生するかわかりません。パッチバージョンを自動更新するツールを使用する場合は問題になる可能性があります。
先に進んでLombokを使ってください。必要ならば後でコードを "delombok"することができます http://projectlombok.org/features/delombok.html
個人的に（そしてそれゆえに主観的に）私はLombokを使用すると自分のコードがIDEやhashcode＆equalsのような複雑なメソッドの実装と比べて表現力が向上することを表現するようになりました。
使用するとき
@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })
どのIDEや独自の実装よりも、Equals＆HashCodeの一貫性を保ち、どのフィールドが評価されるかを追跡する方がはるかに簡単です。これは特に定期的にフィールドを追加/削除しているときに特に当てはまります。
同じことが@ToStringアノテーションとそのパラメータにも当てはまります。これは、包含/除外されたフィールド、ゲッターやフィールドアクセスの使用に関する望ましい動作を明確に伝え、super.toString()を呼び出さないようにします。
また、クラス全体を@Getterまたは@Setter(AccessLevel.NONE)でアノテーションを付けること（およびオプションで任意の異なるメソッドをオーバーライドすること）によって、フィールドに使用できるメソッドがすぐにわかります。
利点は何度も続きます..
私の考えでは、コードを減らすことではなく、Javadocや実装からコードを理解する必要があるのではなく、達成したいことを明確に伝えることです。縮小されたコードは、分岐メソッドの実装を簡単に見つけることを可能にします。
ロンボクはすごいですが….
Lombokは、新しいソースファイルを生成しないという点で、注釈処理の規則を破ります。つまり、ゲッター/セッターなどが存在すると予想される場合は、他のアノテーションプロセッサと一緒に使用することはできません。
注釈処理は一連のラウンドで実行されます。各ラウンドで、それぞれが走る順番を得ます。ラウンドが完了した後に新しいJavaファイルが見つかった場合は、別のラウンドが始まります。このように、注釈プロセッサが新しいファイルを生成するだけであれば、注釈プロセッサの順序は関係ありません。 lombokは新しいファイルを生成しないので、新しいラウンドは開始されず、したがってlombokコードに依存する一部のAPは期待通りに動作しません。これはmapstructを使用しているときの私にとって大きな痛みの源でした。また、デロンボキングはログ内の行番号を破壊するので有用な選択肢ではありません。
私は最終的にlombokとmapstructの両方で動作するビルドスクリプトをハッキングしました。しかし、私はロンボクを落としたいのですが、それがどれほどハッピーなのか - 少なくともこのプロジェクトでは。私は他のものでいつもロンボクを使っています。
長期メンテナンスリスクもあります。まず、Lombokが実際にどのように機能するのかについて読むことをお勧めします。開発者からのいくつかの回答 ここ 。
公式サイトには 欠点のリスト も含まれています。
それは完全なハックです。非公開のAPIを使用する。先行キャスト（javacで実行されている注釈プロセッサがAnavationAcessorの内部実装であるJavacAnnotationProcessorのインスタンスを取得することを知っているので（インターフェース）、実際のASTに到達するために使用される2つの追加メソッドがあるのです） 。
Eclipseでは、それは間違いなくさらに悪い（そしてより堅牢） - Eclipseの文法とパーサーのクラスにコードを注入するためにJavaエージェントが使われています。もちろん、これは完全に非公開のAPIで、完全に立ち入り禁止です。
もしあなたがlombokが標準APIを使ってできることができたら、私はそのようにしたでしょう、しかしあなたはできません。それでも、その価値のために、私はJava 1.6上で動作するEclipse v3.5用のEclipseプラグインを開発しましたが、変更を加えることなくJava 1.5上で動作するEclipse v3.4にも作用しました。
要約として、Lombokは開発時間をいくらか節約するかもしれませんが、後方互換性のないjavacアップデート（脆弱性の軽減など）があれば、Lombokは古いバージョンのJavaにとどまるかもしれません。内部APIこれが重大なリスクかどうかは、明らかにプロジェクトによって異なります。
私は1年間ほぼすべてのプロジェクトでLombokを使用しましたが、残念ながらそれを削除しました。最初はとてもきれいな開発方法でしたが、新しいチームメンバーのために開発環境を設定することはそれほど簡単で直接的ではありません。それが頭痛になったとき、私はちょうどそれを取り除きました。しかし、それは良い仕事であり、設定するにはさらに簡単さが必要です。
私は遅れているのですが、誘惑には耐えられません。あなたがロンボク島で見つけたたくさんの良い考えはScala言語の一部です。
あなたの質問に関して：あなたの開発者がScalaよりもLombokを試してみるのは間違いなく簡単です。試してみて、気に入ったらScalaを試してください。
免責事項として、私もJavaが好きです！
私はロンボク島についていくつかの意見を読みました、そして実際に私はいくつかのプロジェクトでそれを使っています。
まあ、ロンボクとの最初の接触で私は悪い印象を持っていました。数週間後、私はそれが好きになりました。しかし、数ヶ月後、私はそれを使用することで多くの小さな問題を見つけ出しました。だから、ロンボクについての私の最後の印象はそれほどポジティブではありません。
このように考える私の理由：
- IDEプラグインの依存関係。 LombokのIDEサポートはプラグインを通じて行われます。ほとんどの場合、うまく機能していても、将来のIDEのリリースで維持されるのは、常にこのプラグインの人質であり、 言語バージョンでさえ （Java 10+が開発を加速するでしょう）言語）。一例として、Intellij IDE2017.3から2018.1に更新しようとしましたが、実際のlombokプラグインのバージョンに問題があり、プラグインが更新されるのを待つ必要があるため、それができませんでした。あなたがLombokプラグインをサポートしていないもっと代替的なIDEを使いたいのであれば、これも問題です。
- '使用法を見つける'問題。。 Lombokを使用すると、生成されたゲッター、セッター、コンストラクター、ビルダーメソッドなどは表示されません。したがって、これらのメソッドのうちどれがIDEによってプロジェクトで使用されているかを調べる予定がある場合は、これだけできません。この隠されたメソッドを所有するクラスを探します。
- とても簡単なので、開発者はカプセル化を破っても構いません。私はそれが本当にロンボク島からの問題ではないことを知っています。しかし、私は開発者がどのメソッドを見えるようにする必要があるかどうかをもう制御しないという大きな傾向を見ました。そのため、多くの場合、クラスが実際に公開する必要があるメソッドを考えずに、
@Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorアノテーションをコピーして貼り付けるだけです。 - ビルダーオブセッション©私はこの名前を発明しました（降りてください、Martin Fowler）。冗談は別ですが、Builderはとても簡単に作成できるので、クラスが2つのパラメータしか持たない場合でも、開発者はコンストラクタや静的コンストラクタメソッドの代わりに
@Builderを使用することを好みます。時には彼らはMyClass.builder().name("Name").build().create()のような奇妙な状況を作り出して、lombok Builderの中にBuilderを作成しようとさえします。 - リファクタリング時の障害。たとえば、
@AllArgsConstructorを使用していて、コンストラクタにもう1つパラメータを追加する必要がある場合は、IDEを使用して、インスタンス化されているすべての場所（主にテスト）にこの追加パラメータを追加できます。クラス。 - Lombokと具体的な方法を組み合わせてください。 getter/setter/etcを作成するのに、すべてのシナリオでLombokを使用することはできません。だから、あなたはあなたのコードにこれら二つのアプローチが混在しているのを見るでしょう。しばらくすると慣れますが、言語がハックされたように感じます。
他の答えが言ったように、あなたがJavaの冗長性に怒っていてそれに対処するためにLombokを使うなら、Kotlinを試してください。
私が自分のチームにこのプロジェクトを見せたとき、熱意は高かったので、チームの反応を恐れてはいけないと思います。
ROIに関しては、統合するのは簡単で、基本的な形式でコードを変更する必要はありません。 （クラスに単一のアノテーションを追加するだけです）
そして最後に、気が変わったら、unlombokを実行するか、IDEにこれらのセッター、ゲッター、そしてctorsを作成させてください。になります）
Lombokの@ToStringを使いたかったが、すぐにIntellij IDEAでのプロジェクトの再構築時にランダムなコンパイルエラーに直面しました。インクリメンタルコンパイルが正常に完了する前に、compileを数回ヒットする必要がありました。
Jdk 1.6.0_39と1.6.0_45の下で、lombok 1.12.2と0.9.3をIntellij IDEA12.1.6と13.0で試しました。
生成されたメソッドをデロンボークされたソースから手動でコピーし、より良い時期までlombokを保留にしなければなりませんでした。
更新
この問題はパラレルコンパイルが有効になっている場合にのみ発生します。
問題を提出しました： https://github.com/rzwitserloot/lombok/issues/648
更新
mplushnikovが2016/01/30にコメントしました：
新しいバージョンのIntellijには、このような問題はもうありません。ここで閉じることができると思います。
更新
可能であれば、Java + Lombokから Kotlin に切り替えることを強くお勧めします。 Lombokが回避しようとしているすべてのJavaの問題を根本的に解決したので。
私がLombokについて考えているのは、それが単に定型的なJavaコードを書くためのショートカットを提供するだけだということです。
ボイラープレートJavaコードを書くためのショートカットを使うことになると、私はIDEによって提供されるそのような機能に頼るだろう - Eclipseのように、メニューSource> Generate Getters and Settersに行くことができるゲッターとセッターを生成します。
私はこれをロンボクのような図書館に頼ることはしませんでした。
- それは代替構文の間接層（
@Getter、@Setterなどのアノテーションを読む）であなたのコードを汚染します。 Javaの代替構文を学ぶのではなく、Lombokのような構文をネイティブに提供する他の言語に切り替えます。 - Lombokでは、コードを処理するためにLombokがサポートしているIDEを使用する必要があります。この依存関係は、重要なプロジェクトにとってかなりのリスクをもたらします。オープンソースのLombokプロジェクトには、入手可能なさまざまなバージョンのJava IDEのさまざまなバージョンをサポートし続けるのに十分なリソースがありますか？
- オープンソースのLombokプロジェクトには、将来登場する新しいバージョンのJavaを引き続きサポートするのに十分なリソースがありますか？
- 私はまた、Lombokが実行時にあなたのバイトコードを扱う広く使われているフレームワーク/ライブラリ（Spring、Hibernate、Jackson、JUnit、Mockitoのような）との互換性の問題を持ち込むかもしれないことを心配している。
結局のところ、私は自分のJavaをLombokで「スパイスアップ」するのを好みません。
オブジェクト（Java Bean）をCSVファイルに整列化したときにLombokおよびJackson CSVの問題が発生しました。次に、重複している列を削除し、Lombokの@Data注釈を削除しましたそしてマーシャリングはうまくいきました。
お勧めしません。私はこれを使用していましたが、それからNetBeans 7.4を使用していたときにコードが混乱していました。プロジェクト内のすべてのファイルからlombokを削除します。 delombokがあります、しかし、どうすればそれが私のコードを台無しにしないだろうということを確かめることができます。 lombokを削除して通常のJavaスタイルに戻すためだけに数日を費やす必要があります。辛すぎます….
私はまだLombokを使用したことがありません - それが私のリストの次のリストですが、あたかもJava 8が重大な問題を引き起こしているかのように聞こえます。私の情報源は https://code.google.com/p/projectlombok/issues/detail?id=451 です。