Project Lombokを使用しても安全ですか？ [閉まっている

StackOverflow https://stackoverflow.com/questions/3852091

  •  27-09-2019
  •  | 
  •  

質問

あなたが知らない場合 プロジェクトロンボク Javaの迷惑の一部を次のようなもので助けます 注釈付きのゲッターとセッターを生成します そしてさえ @dataのシンプルなJavabeanのような世代. 。特に、ゲッターで構築して隠す必要がある最大7つの異なるフィールドがある50の異なるイベントオブジェクトで、それは本当に私を助けることができます。これでほぼ1000行のコードを削除できました。

しかし、私は長期的には、それが後悔の決定になるのではないかと心配しています。 Flamewarsが噴火します ##Java Freenode チャネル私がそれを言及するとき、コードスニペットを提供すると、考えられるヘルパーが混同されます、 人々はJavadocの行方不明について不平を言うでしょう, 、そして将来の詐欺師はとにかくそれをすべて削除するかもしれません。私は本当にポジティブを楽しんでいますが、ネガティブが心配です。

SO：小規模または大規模なプロジェクトでLombokを使用しても安全ですか？プラスの効果はネガの価値がありますか？

役に立ちましたか？

解決

Project Lombokが提案された新しいプロジェクトに大きな技術的利点を提供することをすでに決定したようです。 （最初から明確にするために、私はプロジェクトロンボクについて、何らかの方法で特別な見解を持っていません。）

プロジェクトLombok（または他のゲームを変えるテクノロジー）を一部のプロジェクト（オープンソースまたはその他のワイズ）で使用する前に、プロジェクトの利害関係者がこれに同意することを確認する必要があります。これには、開発者と重要なユーザー（正式または非公式のスポンサーなど）が含まれます。

あなたはこれらの潜在的な問題に言及します：

Flamewarsは、## Java FreeNodeチャンネルで噴火します。

簡単。 Flamewarsに無視 /参加しないでください。または、単にLombokについて言及しないでください。

コードスニペットを提供すると、考えられるヘルパーが混同されます。

プロジェクト戦略がロンボクを使用する場合、可能なヘルパーはそれに慣れる必要があります。

人々はJavadocの行方不明について不平を言うでしょう、

それが彼らの問題です。右心の誰も、組織のソースコード /ドキュメントルールをサードパーティのオープンソースソフトウェアに厳密に適用しようとしません。プロジェクトチームは、使用されているテクノロジーに適したプロジェクトソースコード /ドキュメント標準を自由に設定できる必要があります。

(ファローアップ -Lombokの開発者は、合成されたゲッターとセッターの方法に対するJavadocのコメントを生成しないことが問題であることを認識しています。これがプロジェクトの大きな問題である場合、1つの選択肢がロンボクパッチを作成して提出してこれに対処することです。

とにかく将来の詐欺師はそれをすべて削除するかもしれません。

それはオンではありません！合意されたプロジェクト戦略がLombokを使用することである場合、その後、コードを無償で脱いでいるコミットナーは懲らしめられ、必要に応じてコミット権が撤回されます。

もちろん、これはあなたが開発者を含む利害関係者からの賛同を得ていることを前提としています。そして、それはあなたがあなたの大義を議論する準備ができていると仮定し、避けられない反対声を適切に処理します。

他のヒント

今日ロンボクの使用を始めたばかりです。これまでのところ、私はそれが好きですが、私が言及したことのない欠点の1つは、サポートをリファクタリングすることでした。

注釈付きのクラスがある場合 @Data, 、フィールド名に基づいて、ゲッターとセッターを生成します。別のクラスでそれらのゲッターのいずれかを使用する場合、フィールドの名前が不十分であると判断します。これらのゲッターとセッターの使用法は見つかりませんでした。古い名前を新しい名前に置き換えます。

Lombokではなく、IDEプラグインを介してこれを行う必要があると思います。

更新（13年1月22日）
Lombokを3か月間使用した後、私はまだほとんどのプロジェクトにそれをお勧めします。しかし、私は上記のものに似た別の欠点を見つけました。

クラスがある場合は、たとえば MyCompoundObject.java それには2人のメンバーがいて、両方とも注釈が付けられています @Delegate, 、 いう myWidgets と myGadgets, 、電話するとき myCompoundObject.getThingies() 別のクラスから、それが Widget また Gadget IDE内のソースにジャンプできなくなる可能性があるからです。

Eclipse「生成デリゲートメソッド...」を使用すると、同じ機能が提供され、迅速でソースジャンプが提供されます。欠点は、重要なものから焦点を当てたボイラープレートコードでソースを妨害することです。

アップデート2（13年2月26日）
5か月後、私たちはまだロンボクを使用していますが、他にも迷惑がかかります。宣言されたゲッターとセッターの欠如は、新しいコードに慣れようとしているときに迷惑になる可能性があります。

たとえば、呼ばれるメソッドが表示された場合 getDynamicCols() しかし、私はそれが何であるかわかりません。この方法の目的を決定するためにジャンプするためのいくつかの余分なハードルがあります。ハードルのいくつかはロンボクで、いくつかはロンボクスマートプラグインが不足しています。ハードルは次のとおりです。

  • Javadocsの欠如。私がフィールドをJavadocするなら、私はゲッターとセッターがロンボクコンピレーションステップを通してそのジャバドックを継承することを願っています。
  • メソッド定義にジャンプすると、クラスにジャンプしますが、ゲッターを生成したプロパティではありません。これはプラグインの問題です。
  • 明らかに、メソッドを生成またはコーディングしない限り、ゲッター/セッターにブレークポイントを設定することはできません。
  • 注：私が最初に思ったように、この参照検索は問題ではありません。ただし、アウトラインビューを可能にする視点を使用する必要があります。ほとんどの開発者にとっては問題ではありません。私の問題は、私が私をフィルタリングしていたマイリンを使用していることでした Outline 見るので、私は方法を見ませんでした。 参照の不足検索。誰が呼んでいるのか見たいなら getDynamicCols(args...), 、参照を検索できるように、セッターを生成またはコーディングする必要があります。

更新3（13年3月7日）
日食で物事を行うさまざまな方法を使用することを学ぶと思います。 Lombok生成方法で実際に条件付きブレークポイント（BP）を設定できます。を使用して Outline 表示すると、メソッドを右クリックできます Toggle Method Breakpoint. 。次に、BPにヒットすると、デバッグを使用できます Variables 生成されたメソッドがパラメーターに名前を付けたもの（通常はフィールド名と同じ）を確認し、最後に、 Breakpoints BPを右クリックして選択して選択します Breakpoint Properties... 条件を追加します。良い。

更新4（13年8月16日）
NetBeansは、Maven POMでLombok依存関係を更新するときにそれを好まない。プロジェクトは引き続きコンパイルされていますが、ロンボクが作成している方法を確認できないため、ファイルがコンパイルエラーを持つためにフラグが付けられます。 NetBeansキャッシュをクリアすると、問題が解決します。 Eclipseにあるような「クリーンプロジェクト」オプションがあるかどうかはわかりません。マイナーな問題ですが、それを知らせたかったのです。

更新5（14年1月17日）
ロンボクはいつもグルーヴィー、または少なくとも groovy-eclipse-compiler. 。コンパイラのバージョンをダウングレードする必要がある場合があります。Maven GroovyとJava + Lombok

更新6（14年6月26日）
警告の言葉。ロンボクはわずかに中毒性があり、何らかの理由でそれを使用できないプロジェクトに取り組んでいる場合、それはあなたの小便を困らせるでしょう。まったく使用しないでください。

更新7（14年7月23日）
これは、直接対処するため、少し興味深いアップデートです 安全性 OPが尋ねたロンボクを採用すること。

v1.14の時点で、 @Delegate 注釈は実験的なステータスに降格されました。詳細は彼らのサイトに文書化されています（Lombok Delegate Docs).

問題は、この機能を使用している場合、バックアウトオプションが限られていることです。オプションは次のとおりです。

  • 手動で削除します @Delegate 注釈と生成/手コードデリゲートコード。注釈内で属性を使用している場合、これは少し難しいです。
  • DeLombokを持っているファイル @Delegate 注釈と、あなたが望む注釈に戻って追加するかもしれません。
  • Lombokを更新したり、フォークを維持したりしないでください（または、体験機能を使用して生きる）。
  • デロンボクプロジェクト全体を使用して、Lombokの使用をやめてください。

私の知る限り、 DeLombokには、注釈のサブセットを削除するオプションがありません;少なくとも単一のファイルのコンテキストでは、それはすべてか何もありません。私は開きました この機能をリクエストするチケット デロンボクの旗がありますが、近い将来それを期待していません。

更新8（14年10月20日）
それがあなたのためのオプションである場合、GroovyはLombokのほとんどの利点のほとんどを提供し、さらに他の機能を含む多くのボートが提供します。 @delegate. 。あなたがそのアイデアを力に売るのに苦労していると思うなら、 @CompileStatic また @TypeChecked それがあなたの大義に役立つかどうかを確認するための注釈。実際には、 Groovy 2.0リリースの主な焦点は静的な安全でした.

更新9（15年9月1日）
ロンボクはまだです 積極的に維持され、強化されました, 、これは養子縁組の安全レベルに合わせています。 @ビルダー 注釈は私のお気に入りの新機能の1つです。

更新10（15年11月17日）
これは、OPの質問に直接関係しているわけではないように見えるかもしれませんが、共有する価値があります。あなたが書いたボイラープレートコードの量を減らすのに役立つツールを探しているなら、あなたもチェックアウトすることができます Google Auto - 特に 自動価値. 。あなたが彼らを見るなら スライドデッキ, 、リストは、彼らが解決しようとしている問題の可能な解決策としての可能性のある解決策として。彼らがロンボクのリストは次のとおりです。

  • 挿入されたコードは目に見えません（生成する方法を「表示する」ことはできません）[ed note-実際にもできますが、逆コンパイラが必要です
  • コンパイラハックは標準以外で壊れやすいです
  • 「私たちの見解では、あなたのコードはもはや本当にJavaではありません」

彼らの評価にどれだけ同意するかはわかりません。また、スライドに文書化されている自動価値の短所を考えると、Lombokに固執します（Groovyがオプションでない場合）。

アップデート11（16年2月8日）
わかった 春のルー いくつかあります 同様の注釈. 。 Rooがまだ何かであることを知って少し驚いたので、注釈のドキュメントを見つけるのは少し荒いです。また、削除はデロンボックほど簡単には見えません。ロンボクはより安全な選択のようです。

更新12（16年2月17日）
私が現在取り組んでいるプロジェクトのためにロンボクを持ち込むのが安全である理由の正当性を考え出そうとしている間、私は追加された金の一部を見つけました v1.14 - 構成システム！これは、チームが危険または望ましくないと思われる特定の機能を軽視するようにプロジェクトを構成できることを意味します。さらに良いことに、異なる設定でディレクトリ固有の構成を作成することもできます。これは素晴らしいです。

更新13（16年10月4日）
この種のことがあなたにとって重要な場合、 オリバー・ギルケ 安全だと感じました Spring Data RestにLombokを追加します.

更新14（17年9月26日）
指摘されているように @gavenkoa OPSの質問に関するコメントで、 JDK9コンパイラサポートはまだ利用できません （問題＃985）。また、ロンボクチームが回避するのが簡単な修正ではないように聞こえます。

更新15（18年3月26日）
Lombok Changelogはv1.16.20 "の時点で示されていますJDK1.9でLombokをコンパイルすることが可能になりました" それでも #985 まだ開いています。

ただし、JDK9に対応するための変更には、いくつかの壊れた変更が必要でした。すべてが構成デフォルトの変更に分離されています。彼らが壊れた変更を導入したことには少し心配ですが、バージョンは「増分」バージョン番号（v1.16.18からv1.16.20に移動する）のみを掲げました。この投稿は安全性に関するものだったので、あなたが持っていたなら yarn/npm 最新のインクリメンタルバージョンに自動的にアップグレードされたビルドシステムのように、失礼な目覚めに参加するかもしれません。

更新16（19年1月9日）

そうみたいです JDK9の問題は解決されました LombokはJDK10、さらにはJDK11でも、私が知る限りも機能します。

私が気づいたことの1つは、安全の側面から懸念されていたことです。v1.18.2からv1.18.4への変更ログが2つの項目をとしてリストしているという事実です。 BREAKING CHANGE！？ semverの「パッチ」アップデートで壊れた変更がどのように発生するかはわかりません。パッチバージョンを自動設定するツールを使用する場合、問題になる可能性があります。

先に進んでロンボクを使用してください、必要に応じてコードを後でコードを「」 http://projectlombok.org/features/delombok.html

個人的に（したがって、主観的に）Lombokを使用すると、Hashcode＆Equalsなどの複雑な方法のIDE/独自の実装と比較した場合、私が達成しようとしていることについてコードをより表現することがわかりました。

使用するとき 

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

等しいとハッシュコードを一貫性に保ち、どのフィールドが評価されているかを追跡する方が、どのフィールド/独自の実装よりもはるかに簡単です。これは、フィールドを定期的に追加 /削除している場合に特に当てはまります。

同じことがあります @ToString 含まれている /除外されたフィールド、ゲッターまたはフィールドアクセスの使用、または電話をかけないかどうかに関する望ましい動作を明確に伝える注釈とそのパラメーター super.toString().

そして再びクラス全体に注釈を付けます @Getter また @Setter(AccessLevel.NONE) （そして、オプションで異なる方法を無効にします）フィールドで利用可能な方法はすぐに明らかになります。

利点は延々と続きます。

私の考えでは、それはコードを減らすことではなく、Javadocや実装からそれを理解する必要があるのではなく、達成したいことを明確に伝えることです。コードを減らすと、Divergent-Methodの実装を簡単に見つけることができます。

ロンボクは素晴らしいですが...

Lombokは、新しいソースファイルを生成しないという点で、注釈処理のルールを破ります。これは、ゲッター/セッターなどが存在することを期待する場合、別の注釈プロセッサで使用できないことを意味します。

注釈処理は一連のラウンドで実行されます。各ラウンドで、それぞれが走るターンを取得します。ラウンドが完了した後に新しいJavaファイルが見つかった場合、別のラウンドが開始されます。このようにして、注釈プロセッサの順序は、新しいファイルのみを生成するかどうかは関係ありません。 Lombokは新しいファイルを生成しないため、新しいラウンドは開始されないため、Lombokコードに依存しているAPが予想通り実行されません。これは、MapsTructを使用している間、私にとって大きな痛みの原因であり、Delombok-ingはログのライン数を破壊するため、有用な選択肢ではありません。

最終的に、ロンボクとMapsTructの両方で作業するためにビルドスクリプトをハッキングしました。しかし、少なくともこのプロジェクトでは、それがどれほどハッキーズであるかのためにロンボクを落としたいです。私は他のもので常にロンボクを使用しています。

長期的なメンテナンスリスクもあります。まず、Lombokが実際にどのように機能するかについて読むことをお勧めします。たとえば、その開発者からのいくつかの答え ここ.

公式サイトにはaも含まれています 欠点のリスト, 、Reinier Zwitserlootからのこの引用を含む：

それは完全なハックです。非パブリックAPIを使用します。想定される鋳造（Javacで実行されているアノテーションプロセッサがJavacannotationProcessorのインスタンスを取得することを知っています。これは、AnnotationProcessor（インターフェイス）の内部実装であり、ライブASTで取得するために使用されるいくつかの追加の方法があることがあります） 。

Eclipseでは、間違いなく悪い（そしてさらに堅牢） - JavaエージェントがEclipse GrammarおよびParserクラスにコードを注入するために使用されます。

Lombokが標準のAPIで行うことができれば、私はそれをそのようにしたでしょうが、できません。それでも、その価値のために、私はJava 1.6で実行されているEclipse v3.5のEclipseプラグインを開発しました。変更を加えることなく、Java 1.5で実行されるEclipse v3.4でも機能したため、完全に脆弱ではありません。

要約として、ロンボクは開発時間を節約するかもしれませんが、バックワードに互換性のないJavacアップデート（脆弱性緩和など）がある場合、ロンボクはあなたが古いバージョンのJavaにとどまる可能性があります。内部API。これが深刻なリスクであるかどうかは明らかにプロジェクトに依存します。

私はロンボクについていくつかの意見を読みました、そして実際に私はいくつかのプロジェクトでそれを使用しています。

まあ、ロンボクとの最初の接触で、私は悪い印象を持っていました。数週間後、私はそれが好きになり始めました。しかし、数ヶ月後、私はそれを使用して多くの小さな問題を見つけます。したがって、ロンボクについての私の最後の印象はそれほど前向きではありません。

このように考える理由：

  • IDEプラグインの依存関係. 。 LombokのIDEサポートは、プラグインを使用しています。ほとんどの場合、よく働いていても、あなたは常にこのプラグインの人質です。 言語バージョンでさえ （Java 10+は言語の開発を加速します）。たとえば、Intellij IDE 2017.3から2018.1から更新しようとしましたが、実際のLombokプラグインバージョンに問題があるため、プラグインを更新するのを待つ必要があるため、それはできませんでした...これも問題です。 Lombokプラグインのサポートがない、より代替IDEを使用したいと思います。
  • 「使用法を見つける」問題。. 。 Lombokを使用すると、生成されたゲッター、セッター、コンストラクター、ビルダーメソッドなどが表示されません。したがって、これらのメソッドがプロジェクトで使用されていることをIDEによって使用していることを知ることを計画している場合、これだけを行うことはできませんこの隠された方法を所有するクラスを探しています。
  • 開発者がカプセル化を破ることを気にしないほど簡単です. 。私はそれが本当にロンボクからの問題ではないことを知っています。しかし、私は開発者がもはやどのような方法を目にする必要があるかを制御しないより大きな傾向があると思いました。だから、多くの場合彼らはただコピーして貼り付けている @Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructor クラスが実際に公開する必要がある方法を考えずに注釈。
  • ビルダーの執着 ©。私はこの名前を発明しました（降りて、マーティン・ファウラー）。ジョークは別として、ビルダーは非常に簡単に作成でき、クラスには開発者が使用することを好む2つのパラメーターしかない場合でも @Builder コンストラクターまたは静的コンストラクターメソッドの代わりに。時々、彼らはロンボクビルダーの内部にビルダーを作成しようとし、ような奇妙な状況を作成しようとします MyClass.builder().name("Name").build().create().
  • リファクタリングの障壁. 。あなたが使用している場合、例に従って、a @AllArgsConstructor コンストラクターにもう1つのパラメーターを追加する必要があるため、IDEはクラスをインスタンス化しているすべての場所（主にテスト）にこの追加パラメーターを追加するのに役立ちません。
  • ロンボクを具体的な方法と混ぜます. 。すべてのシナリオでLombokを使用してゲッター/セッター/などを作成することはできません。したがって、これらの2つのアプローチがコードに組み合わされているのがわかります。しばらくしてこれに慣れますが、言語のハックのように感じます。

別の答えが言ったように、あなたがJavaの冗長性について怒っていて、それに対処するためにLombokを使用しているなら、Kotlinを試してください。

私は遅れていることを知っていますが、誘惑に抵抗することはできません。ロンボクが好きな人は、スカラを見るべきです。 Lombokで見つけた多くの良いアイデアは、Scala言語の一部です。

あなたの質問について：Scalaよりも開発者にLombokを試してもらう方が間違いなく簡単です。試してみてください。彼らがそれを気に入ったら、Scalaを試してみてください。

免責事項として：私もJavaが好きです！

私は1年間、ほとんどすべてのプロジェクトでロンボクを使用しましたが、残念ながらそれを削除しました。当初は非常にクリーンな開発方法でしたが、新しいチームメンバーのための開発環境を設定することは、非常に簡単で簡単ではありません。それが頭痛になったとき、私はそれを削除しました。しかし、それは良い仕事であり、セットアップにもっと簡単にする必要があります。

私がチームにプロジェクトを示したとき、熱意は高かったので、チームの反応を恐れるべきではないと思います。

  • ROIに関しては、統合するためのスナップであり、基本的な形式のコード変更は必要ありません。 （クラスに1つの注釈を追加するだけです）

  • そして最後に、あなたがあなたの心を変える場合、あなたはUnlombokを実行するか、あなたのIDEにこれらのセッター、ゲッター、およびCTORを作成させることができます（あなたのPojoがどれほどクリアになるかを見ると誰も求めないと思います）

ロンボクを使いたかった @ToString しかし、すぐにIntellijのアイデアでプロジェクト再構築のランダムコンパイルエラーに直面しました。インクリメンタルコンピレーションが成功する前に、コンパイルを数回ヒットする必要がありました。

JDK 1.6.0_39および1.6.0_45の下でLombokプラグインを使用せずに、Intellij Idea 12.1.6と13.0でLombok 1.12.2と0.9.3の両方を試しました。

Delomboked Sourceから生成されたメソッドを手動でコピーし、より良い時までLombokを保留にしなければなりませんでした。

アップデート

問題は、並列コンパイル有効でのみ発生します。

問題を提出しました：https://github.com/rzwitserloot/lombok/issues/648

アップデート

Mplushnikovは2016年1月30日にコメントしました。

Intellijの新しいバージョンには、そのような問題はもうありません。ここで閉じることができると思います。

アップデート

Java+LombokからLombokから切り替えることを強くお勧めします コトリン もし可能なら。ロンボクが回避しようとしているすべてのJavaの問題をゼロから解決したように。

Lombokについての私の見解は、BolilerPlate Javaコードを書くためのショートカットを単に提供するだけだということです。
BolilerPlate Javaコードを書くためにショートカットを使用する場合、私はIDEが提供するそのような機能に依存します - Eclipseのように、メニューソースに移動して、ゲッターとセッターを生成するためのゲッターとセッターを生成できます。
私はこれについてロンボクのようなライブラリに頼らないでしょう：

  1. それはあなたのコードを代替構文の間接層で汚染します（読む @Getter, @Setter, など。注釈）。 Javaの代替構文を学ぶのではなく、Lombokのような構文のようにネイティブに提供する他の言語に切り替えます。
  2. Lombokは、コードを使用するためにLombokサポートIDEを使用する必要があります。この依存関係は、非自明のプロジェクトにかなりのリスクをもたらします。オープンソースのロンボクプロジェクトには、さまざまなバージョンの幅広いJava IDEが利用可能なサポートを提供し続けるのに十分なリソースがありますか？
  3. オープンソースのロンボクプロジェクトには、将来的に来るJavaの新しいバージョンのサポートを提供し続けるのに十分なリソースがありますか？
  4. また、ロンボクが、実行時にバイトコードで動作する広く使用されているフレームワーク/ライブラリ（Spring、Hibernate、Jackson、Junit、Mockitoなど）の互換性の問題を導入する可能性があることにも緊張しています。

全体として、私はロンボクと私のジャバを「スパイス」することを好まないでしょう。

私は問題に遭遇しました ロンボク と ジャクソンCSV, 、私が自分のオブジェクト（Java Bean）をCSVファイル、列が複製した列にマーシャリングしたとき、Lombokの@Dataアノテーションを削除し、マーシャライズを正常に機能させました。

お勧めしません。以前は使用していましたが、NetBeans 7.4を使用して作業したとき、コードを台無しにしていました。プロジェクトのすべてのファイルでLombokを削除する必要があります。デロンボックがありますが、どうすればコードをねじ込まないようにすることができますか。ロンボクを削除し、普通のジャワスタイルに戻るためだけに何日も費やさなければなりません。私はちょうどスパイシーすぎる...

私はまだLombokを使用しようとしていません - それは私のリストの次の/次のことですが、Java 8が重大な問題を引き起こしたかのように聞こえますが、1週間前の時点で修復作業はまだ進行中でした。そのための私の情報源はです https://code.google.com/p/projectlombok/issues/detail?id=451 .

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top