問題タブ [jsr305]

私は、Findbugs で使用する jsr 305 アノテーション、具体的には、バグを回避できる @CheckForNull アノテーションを試してきました。ビルド パスに jsr305.jar と annotations.jar を追加しましたが、findbugs でバグが見つかりません。Eclipse Findbugs プラグインで Eclipse を使用しています。以下は、同じバグを示すいくつかのサンプル コードですが、findbugs を実行してもバグが見つかりません。Eclipse Galileo と Ganymede でこれを試しました。

アノテーションには 2 つの異なる JSR があるようです。

JSR-305: ソフトウェア欠陥検出の注釈 (追加リソース)
JSR-308: Java 型の注釈 (追加リソース)

どちらも静的コード分析を対象としているようです。

あなたは知っていますか：

• どちらが Java SE 7 と Java EE 6 のどちらになるのでしょうか?
• 各JSRはどの程度「安定」していますか?
• 一方が他方に取って代わる（または廃止する）か？

注: 私が話しているこれらの注釈は、JSR305 で指定されています。

私は最新の Findbugs (1.3.9) を使用しており、@ Nonnull で注釈が付けられたフィールドが null に割り当てられている場合、エラーを正しく検出します。

しかし、私のプロジェクトでは、「null 以外のロジック」がデフォルトのケースです。null は 5% のケースでのみ明示的に許可されていると言え ます。

そのため、フィールドの 95% に @Nonnull のアノテーションを付けるのは非常に不便です。これらの 5% のフィールドに @Nullable で注釈を付けたいと思います。

パッケージ全体に @Nonnull のアノテーションを付けようとしましたが、何も変わりません。

では、どういうわけかデフォルトのロジックを指定することは可能ですか?

JSR305 vs. JSR308 (Java Type Annotations) - どちらが標準になるのかという質問を見てきました。JSR 308とJSR 305の違いを理解しています。

また、現時点で 308 は Java 7 向けに予定されており、305 は予定されていないことも理解しており、305 の全体的なステータスに興味があります。

具体的には、私はいくつかのプロジェクトでGoogle CollectionsとJSR-305を使用しており ( Guice のベスト プラクティスの 1 つが提唱しているものと同様の方法で)、より「将来の方向性」に適した方法を使用する必要があるかどうか疑問に思っていました。代わりは。これについては JSR-305 グループでも質問する予定ですが、そのグループはあまり活動がなく、ここに誰か詳しい情報があるかどうか疑問に思っていました。

注釈を認識hashCodeして自動的に生成するように Eclipse を構成する方法はありますか? 現在、私のEclipseは、マークされたフィールドであっても、不要なチェックでコードを生成します。equals@NonNullnull@NonNull

FindBugs は、これらの null チェックが冗長であるという警告を発することに注意してください。もちろん、メソッドに追加することはでき ますが、それは FindBugs の役割とそもそも@edu.umd.cs.findbugs.annotations.SuppressWarnings("RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE")の役割を損なうようです。@NonNull

最善の解決策は、Eclipse に JSR 305 を認識させ、それに応じてチェックなしで生成させるequalsことです (hashCodeいずれにせよそうである場合は、契約違反が発生したため、自然にスローされるようにします)。nullnullNullPointerException

それとは別に、Eclipse によって生成されたequalsとテンプレートをカスタマイズする方法があると便利です。hashCode

関連する質問

• Eclipse の equals() / hashCode() で getter を使用する
• Eclipse に hashCode を生成させ、HashCodeBuilder および EqualsBuilder と同等にすることは可能ですか?

JSR 305 または IntelliJ 用の Jetbrains 独自の注釈のいずれかで使用できるようになったコード検査機能が本当に気に入っています。残念ながら、両方の実装 (JSR 305 と Jetbrains の) はうまく混在しません。

• IntelliJ は明らかに独自の注釈セットのみを理解し、それらを非常にうまく統合します。
• 私の Maven ビルドで Findbugs を使用すると、JSR-305アノテーションのみがサポートされます。

唯一可能な回避策は、JSR-305を使用し、IntelliJ でFindbugsプラグインを使用することです。誰かがより良いアイデアを持っていますか? (IDE を変更するとは言わないでください ;))。

ありがとうトーマス

のドキュメントに@ParametersAreNonnullByDefaultは、次のように書かれています。

この注釈をパッケージ、クラス、またはメソッドに適用して、その要素のメソッド パラメータがデフォルトで非 null であることを示すことができます。

メソッドの戻り値の型/値がそのパラメーターであるとは考えていません。それはその署名の一部にすぎないので、これは私にはあいまいです.

メソッドのJavaチュートリアルは私のように考えているようです。

Joachim Sauerが彼の回答のコメント セクションで指摘したように、名前@ParametersAreNonnullByDefault( parameters ) は、この注釈がメソッドの戻り値の型/値には適用されないことを明確に示しているはずです。私は盲目でした！:) ありがとうヨアヒム！

これに照らして、私はどこかに@EverythingIsNonnullByDefault存在するべきだとしか言えません。:)

Eclipse での @Nonnull および @Nullable アノテーションのチェックは、初期のベータ版です。最大の問題は、Java API の null 動作を認識していないことです。

現在、他に優れたプラグインはありますか?

JSR-305はコードの静的分析に関するものですが。その実行時の対応物はまだ準備ができていません。私の質問に続いて、メソッドパラメーターがそれらのパラメーターの注釈に基づいて正しくないことを検出できる適切な注釈プロセッサがあるかどうかを尋ねたいと思いますか?

=== 編集 ===

私が実際に探しているのは、モデルの検証 (モデル = Bean のコレクション) ではなく、テスト スイートにシームレスに統合できるアスペクト ウィービングのようなものです。

私の質問はこれのフォローアップです。

FindBugsの過去のバージョンでは、パッケージ内のすべてのフィールド@DefaultAnnotation(Nonnull.class)をとして使用または指定することが可能でした。FindBugs（2.0）の現在のバージョンでは、非推奨であり、代わりにJSR-305を使用する必要があります。しかし、JSR-305は、（現在は非推奨の）FindBugsアノテーションがカバーするすべてをカバーしているようには見えません。@DefaultAnnotationForFields(Nonnull.class)@Nonnull@DefaultAnnotation@DefaultAnnotationForFields

javadocは、いくつかの代替案を提案しています。

• @ParametersAreNonnullByDefault。これは（明らかに）パラメータにのみ適用され、メンバーフィールドには適用されません。
• @CheckReturnValue、タイプまたはパッケージに適用された場合。繰り返しますが、これはメンバーフィールドには適用されません。
• @TypeQualifierDefault。多分これは私が望むことをすることができます、しかし私はそれがどのように機能するか理解していません、そして私はいくつかの不可解なjavadocを除いて、その使用法や意図に関するドキュメントや例を見つけることができません。独自の注釈を作成するのに役立つと思いますが、すべてのツール（FindBugs、Eclipseなど）がこの新しい注釈を正しく（またはまったく）解釈することを確認できますか？

javadocは、その非推奨に対処する方法についてのヒントを提供していません。

それで、FindBugsやJSR-305の現在のバージョンを使用して、特定のパッケージ（または特定のクラス）のすべてのメンバーフィールドがとして扱われることになっていることをどのように示す必要があります@Nonnullか？それも可能ですか？