Java 8 型注釈 (JSR 308) により、型チェッカーは静的コード分析を実行できます。たとえば、チェッカー フレームワークは、注釈を介してnullの可能性をチェックでき@NonNullます。
さまざまなプロジェクトが独自のNonNullアノテーションを定義しています。たとえば、次のようになります。
org.checkerframework.checker.nullness.qual.NonNulledu.umd.cs.findbugs.annotations.NonNulljavax.annotation.Nonnulljavax.validation.constraints.NotNulllombok.NonNullorg.eclipse.jdt.annotation.NonNull- など ( Checker Framework マニュアルのセクション 3.7 を参照)
このような注釈については、通常は実行時に必要ないため、 が@interfaceを持つことを期待します。@Retention(RetentionPolicy.CLASS)最も重要なことは、コードがそれぞれのライブラリにランタイムの依存関係を持たないことです。
whileorg.eclipse.jdt.annotation.NonNullこのアプローチに従いますが、(JSR 305) やそれ自体など、他のほとんどのNonNullアノテーションには. これらの注釈に特別な理由はありますか?javax.annotation.Nonnullorg.checkerframework.checker.nullness.qual.NonNull@Retention(RetentionPolicy.RUNTIME)RetentionPolicy.RUNTIME
明確化: Checker Framework は、下位互換性のためにコメント内の注釈をサポートしています。ただし、実行時の依存関係を回避するためだけに Java 8 でそれらを使用するのは、汚いハックのように思えます。