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