今日ロンボクを使い始めました。これまでのところ私はそれを気に入っていますが、言及されていなかった1つの欠点はリファクタリングのサポートでした。
で注釈が付けられたクラスがある場合@Data、フィールド名に基づいてゲッターとセッターが生成されます。これらのゲッターの1つを別のクラスで使用する場合、フィールドの名前が適切でないと判断すると、それらのゲッターとセッターの使用法が見つからず、古い名前が新しい名前に置き換えられます。
これはLombok経由ではなくIDEプラグイン経由で行う必要があると思います。
更新（2013年1月22日）
Lombokを3か月間使用した後も、ほとんどのプロジェクトで推奨しています。しかし、上に挙げたものと同様の別の欠点を見つけました。
あなたはクラスを持っている場合は、と言うMyCompoundObject.javaことは、2人のメンバー、と注釈付きの両方を持っている@Delegate、と言うmyWidgetsと、myGadgetsあなたが呼び出すときに、myCompoundObject.getThingies()別のクラスから、それはそれはに委任だかどうかを知ることは不可能ですWidgetかGadgetあなたはIDE内のソースにはもはやジャンプをすることができるので。
Eclipseの「デリゲートメソッドの生成...」を使用すると、同じ機能が提供され、同様に迅速に、ソースジャンプが提供されます。欠点は、重要なものからフォーカスを外す定型コードでソースが乱雑になることです。
更新2（2013年2月26日）
5か月が経過した後も、私たちはまだロンボクを使用していますが、他にもいくつかの問題があります。宣言されたgetterとsetterがないと、新しいコードに慣れ親しんでいるときに迷惑になることがあります。
たとえば、メソッドが呼び出されgetDynamicCols()たのにそれが何であるかわからない場合、このメソッドの目的を特定するためにジャンプするためにいくつかのハードルがあります。一部のハードルはLombokであり、一部はLombokスマートプラグインの欠如です。ハードルは次のとおりです。
- JavaDocsの欠如。フィールドをjavadocする場合、ゲッターとセッターがLombokのコンパイル手順を通じてそのjavadocを継承することを望みます。
- メソッド定義にジャンプすると、クラスにジャンプしますが、ゲッターを生成したプロパティにはジャンプしません。これはプラグインの問題です。
- メソッドを生成またはコーディングしない限り、getter / setterにブレークポイントを設定することはできません。
- 注：このリファレンス検索は、私が最初に思ったように問題ではありません。ただし、アウトラインビューを有効にするパースペクティブを使用する必要があります。ほとんどの開発者にとって問題ではありません。私の問題は、私の
Outlineビューをフィルター処理するMylynを使用しているため、メソッドが表示されなかったことです。 参照の検索の欠如。呼び出し元を確認したい場合は、参照をgetDynamicCols(args...)検索できるようにセッターを生成またはコーディングする必要があります。
更新3（13年3月7日）
私は、Eclipseでさまざまな方法を使用する方法を学習していると思います。Lombokで生成されたメソッドに実際に条件付きブレークポイント（BP）を設定できます。Outlineビューを使用すると、メソッドを右クリックしてにアクセスできますToggle Method Breakpoint。次に、BPにアクセスすると、デバッグVariablesビューを使用して、生成されたメソッドのパラメーターの名前（通常はフィールド名と同じ）を確認し、最後にBreakpointsビューを使用してBPを右クリックしBreakpoint Properties...、条件を追加することを選択できます。いいね。
UPDATE 4（Aug 16 '13）
Maven pomでLombokの依存関係を更新すると、Netbeansは気に入らなくなります。プロジェクトは引き続きコンパイルされますが、Lombokが作成しているメソッドを認識できないため、ファイルにはコンパイルエラーのフラグが付けられます。Netbeansキャッシュをクリアすると、問題が解決します。Eclipseのように「クリーンプロジェクト」オプションがあるかどうかはわかりません。軽微な問題ですが、知らせたいと思っていました。
更新5（2014年1月17日）
Lombokは、Groovyで常にうまくいくとは限りませんgroovy-eclipse-compiler。少なくとも。コンパイラのバージョンをダウングレードする必要があるかもしれません。
Maven GroovyおよびJava + Lombok
更新6（2014年6月26日）
警告の言葉。ロンボクはやや中毒性があり、何らかの理由でそれを使用できないプロジェクトに取り組む場合、それはあなたの腹を立てます。まったく使用しない方がよい場合があります。
更新7（14/07/23） OPが尋ねたロンボクを採用すること
の安全性に直接対処するため、これは少し興味深い更新です。
v1.14以降、@Delegateアノテーションは試験運用ステータスに降格されました。詳細は彼らのサイト（Lombok Delegate Docs）に文書化されています。
問題は、この機能を使用している場合、バックアウトオプションが制限されていることです。オプションは次のとおりです。
@Delegate注釈を手動で削除し、デリゲートコードを生成/ハンドコードします。アノテーション内で属性を使用している場合、これは少し難しくなります。- アノテーションが付いているファイルをDelombokし、必要な
@Delegateアノテーションを追加します。
- Lombokを更新したり、フォークを保守したりしないでください（または、体験的な機能を使用して生活する）。
- プロジェクト全体をDelombokし、Lombokの使用を停止します。
私の知る限り、Delombokには注釈のサブセットを削除するオプションがありません。少なくとも1つのファイルのコンテキストでは、それはすべてかゼロかです。Delombokフラグを使用してこの機能をリクエストするためのチケットをオープンしましたが、近い将来にはそうは思われません。
更新8（10月20日'14）
Groovyは、Lombokと同じ利点のほとんどに加えて、@Delegateを含む他の機能のボートロードを提供します。考えている力にアイデアを売り込むのが難しいと思う場合は、@CompileStaticまたは@TypeCheckedアノテーションを見て、それがあなたの目的に役立つかどうかを確認してください。実際、Groovy 2.0リリースの主な焦点は静的な安全性でした。
更新9（2015年9月1日）
ロンボクは依然として積極的に維持および強化されており、採用の安全性のレベルによくつながります。@Builderの注釈は私のお気に入りの新機能の1つです。
更新10（2015年11月17日）
これはOPの質問に直接関連しているようには見えないかもしれませんが、共有する価値があります。作成する定型コードの量を減らすのに役立つツールを探している場合は、Google Auto、特にAutoValueを確認することもできます。あなたが彼らのスライドデッキを見れば、彼らが解決しようとしている問題の可能な解決策としてリストロンボク。彼らがロンボクについてリストする短所は次のとおりです：
- 挿入されたコードは非表示です（コードが生成するメソッドを「見る」ことはできません）[ed note-実際には表示できますが、逆コンパイラが必要です]
- コンパイラのハックは非標準で壊れやすい
- 「私たちの見解では、あなたのコードはもはや本当のJavaではありません」
彼らの評価にどれだけ同意するかわかりません。また、スライドに記載されているAutoValueの短所を考慮して、私はLombokを使い続けます（Groovyがオプションでない場合）。
UPDATE 11（16年2月8日）Spring Rooに同様の注釈がいくつかある
ことがわかりました。Rooがまだ物事であり、アノテーションのドキュメントを見つけるのが少しおおざっぱであることを知って少し驚いた。削除もde-lombokほど簡単には見えません。ロンボクはより安全な選択のようです。
UPDATE 12（16年2月17日）
現在取り組んでいるプロジェクトにロンボクを持ち込むことが安全である理由を考え出そうとしたところ、v1.14「構成システム」で追加された金が見つかりました。これは、チームが安全でない、または望ましくないと考える特定の機能を許可しないようにプロジェクトを構成できることを意味します。さらに良いことに、さまざまな設定でディレクトリ固有の設定を作成することもできます。これはすごいです。
更新13（16年10月4日）
この種のことが重要である場合、オリバーギルケは、ロンボクをSpring Data Restに追加しても安全だと感じました。
UPDATE 14（Sep 26 '17） OPに関する質問のコメントで@gavenkoaが
指摘したように、JDK9コンパイラーのサポートはまだ利用できません（Issue＃985）。また、Lombokチームが回避するのは簡単ではないようです。
UPDATE 15（
2018 年3月26日） Lombokの変更ログでは、v1.16.20以降、「＃985がまだ開いている場合でも、JDK1.9でのLombokのコンパイルが可能になりました」と示されています。
ただし、JDK9に対応するための変更には、いくつかの重大な変更が必要でした。構成のデフォルトの変更からすべて分離されています。彼らが重大な変更を導入したことは少し心配ですが、バージョンは「インクリメンタル」バージョン番号（v1.16.18からv1.16.20への変更）のみを増加させました。この投稿は安全性に関するものだったのでyarn/npm、最新のインクリメンタルバージョンに自動的にアップグレードするようなビルドシステムがあると、失礼な目覚めに陥るかもしれません。
更新16（19年1月9日）
そうですJDK9の問題が解決されたとロンボク島は、私の知る限りとしてJDK10、とさえJDK11で動作します。
安全面から懸念されていたのですが、v1.18.2からv1.18.4への変更ログで2つのアイテムがBREAKING CHANGE！？Semverの「パッチ」アップデートで重大な変更がどのように行われるかはわかりません。パッチバージョンを自動更新するツールを使用している場合、問題になる可能性があります。
javac、内部sun.*クラスへのアクセスを開くために、多くのCLIオプションを追加する必要があります（（