Hangi @ NotNull Java ek açıklamasını kullanmalıyım?


998

Kodumu daha okunabilir hale getirmek ve NullPointerExceptions önlemek için IDE kod denetimi ve / veya statik kod analizi (FindBugs ve Sonar) gibi araç kullanmak için arıyorum. Araçların birçoğu her Öteki ile uyumsuz görünüyor @NotNull/ @NonNull/ @Nonnullaçıklama ve benim kodda hepsini listeleyen okumak korkunç olurdu. Hangisinin 'en iyi' olduğuna dair herhangi bir öneriniz var mı? Bulduğum eşdeğer ek açıklamaların listesi:

  • javax.validation.constraints.NotNull
    Statik analiz için değil çalışma zamanı doğrulaması için oluşturuldu.
    belgeleme

  • edu.umd.cs.findbugs.annotations.NonNull
    Kullandığı Findbugs nedenle statik analizi ve Sonar (şimdi Sonarqube )
    dokümantasyon

  • javax.annotation.Nonnull
    Bu, Findbugs ile de çalışabilir, ancak JSR-305 etkin değildir. (Ayrıca bkz: JSR 305'in durumu nedir? ) Kaynak

  • org.jetbrains.annotations.NotNull
    Statik analiz için IntelliJ IDEA IDE tarafından kullanılır.
    belgeleme

  • lombok.NonNull
    Project Lombok'ta kod üretimini kontrol etmek için kullanılır .
    Standart olmadığından yer tutucu ek açıklaması.
    kaynak , dokümantasyon

  • android.support.annotation.NonNull
    Destek ek açıklamaları paketi dokümantasyonu ile sağlanan Android'de mevcut ek açıklama

  • org.eclipse.jdt.annotation.NonNull
    Eclipse tarafından statik kod analizi
    dokümantasyonu için kullanılır


203
apache "ortak" bir ek açıklama ve onu başka bir ek açıklamaya dönüştürebilen bir araç icat etmelidir. çok fazla standart sorununa çözüm yeni bir standart icat etmektir.
dayanılmaz

6
@irreputable apache yeni bir "ortak" icat ederse, diğer projelerle örtüşen 56 versiyonu olacaktır. Ve yine de standart olmaz (standart! = Yaygın). Gerçekten standart bir şey kullansan iyi olur, javax?. *. BTW, bu örneklerde "çok fazla standart" yok, ben sadece 1 veya 2 görüyorum.
ymajoros 27:12

6
Nonnull, onu kullanmamın zorlayıcı bir nedeni olan findbugs (sadece test etti) ile çalışıyor.
Nicolas C

20
Basitçe @NotNull yazarsam, bunu ifade eder com.sun.istack.internal.NotNull. OMG ...
Thomas Weller

3
@MozartBrocchini - Seçenekler, daha önce NullObjects kullandığınız durumlarda kullanışlıdır. Yine de bir çalışma zamanı \ @NotNull ek açıklamasıyla aynı hedefe değinmiyorlar ve sıkıcı açılımı getiriyorlar.
Dave

Yanıtlar:


205

Yana JSR 305 (kimin gol standardize edilerek @NonNullve @Nullable) birkaç yıldır atıl sahiptir Korkarım hiç iyi bir cevap yoktur. Yapabileceğimiz tek şey pragmatik bir çözüm bulmak ve benimki şöyle:

Sözdizimi

Tamamen stilistik bir bakış açısından, IDE'ye, çerçeveye veya Java'nın kendisi dışında herhangi bir araç setine göndermekten kaçınmak istiyorum.

Bu kurallar:

  • android.support.annotation
  • edu.umd.cs.findbugs.annotations
  • org.eclipse.jdt.annotation
  • org.jetbrains.annotations
  • org.checkerframework.checker.nullness.qual
  • lombok.NonNull

Hangi birini bize bırakır javax.validation.constraintsya javax.annotation. Birincisi JEE ile birlikte gelir. Bu, javax.annotationnihayetinde JSE ile gelebilecek ya da hiç gelmeyecek olandan daha iyiyse , bir tartışma konusudur. Şahsen tercih ediyorum javax.annotationçünkü JEE bağımlılığını sevmezdim.

Bu bizi

javax.annotation

ki bu da en kısa olanı.

Hatta daha iyi olurdu tek sözdizimi vardır: java.annotation.Nullable. Diğer paketler mezun olarak javaxhiç javageçmişte, javax.annotation doğru yönde atılmış bir adım olacaktır.

uygulama

Hepsinin temelde aynı önemsiz uygulamaya sahip olmasını umuyordum, ancak ayrıntılı bir analiz bunun doğru olmadığını gösterdi.

Birincisi benzerlikler için:

@NonNullEk açıklamalar, tüm çizgi var

public @interface NonNull {}

dışında

  • org.jetbrains.annotationski bu onu çağırıyor @NotNullve önemsiz bir uygulaması var
  • javax.annotation daha uzun bir uygulaması olan
  • javax.validation.constraintsbu da onu çağırır @NotNullve bir uygulaması vardır

@NullableEk açıklamalar, tüm çizgi var

public @interface Nullable {}

org.jetbrains.annotationsönemsiz uygulamalarıyla (tekrar) hariç .

Farklılıklar için:

Çarpıcı olanı

  • javax.annotation
  • javax.validation.constraints
  • org.checkerframework.checker.nullness.qual

hepsinde çalışma zamanı ek açıklamaları ( @Retention(RUNTIME)) bulunurken

  • android.support.annotation
  • edu.umd.cs.findbugs.annotations
  • org.eclipse.jdt.annotation
  • org.jetbrains.annotations

yalnızca derleme zamanıdır ( @Retention(CLASS)).

Bu SO yanıtında açıklandığı gibi , çalışma zamanı ek açıklamalarının etkisi düşündüğünden daha küçüktür, ancak derleme zamanı olanlara ek olarak araçların çalışma zamanı denetimleri yapmalarını sağlama avantajına sahiptir.

Bir başka önemli fark, kodda ek açıklamaların nerede kullanılabileceğidir. İki farklı yaklaşım vardır. Bazı paketler JLS 9.6.4.1 stil bağlamlarını kullanır. Aşağıdaki tabloda genel bir bakış sunulmaktadır:

                                SAHA YÖNTEMİ PARAMETRESİ LOCAL_VARIABLE 
android.support.annotation XXX   
edu.umd.cs.findbugs.annotations XXXX
org.jetbrains.analımı XXXX
lombok XXXX
javax.validation.constraints XXX   

org.eclipse.jdt.annotation, javax.annotationVe org.checkerframework.checker.nullness.qualbunu yapmak için doğru yolu Bence olduğunu JLS 4.11, tanımlanan bağlamları kullanın.

Bu bizi

  • javax.annotation
  • org.checkerframework.checker.nullness.qual

bu turda.

kod

Daha fazla ayrıntıyı kendiniz karşılaştırmanıza yardımcı olmak için aşağıdaki her ek açıklamanın kodunu listeliyorum. Karşılaştırmayı kolaylaştırmak için yorumları, içe aktarmaları ve @Documentedek açıklamaları kaldırdım . ( @DocumentedAndroid paketindeki sınıflar dışında hepsi vardı ). Çizgileri ve @Targetalanları yeniden sıraladım ve nitelikleri normalleştirdim.

package android.support.annotation;
@Retention(CLASS)
@Target({FIELD, METHOD, PARAMETER})
public @interface NonNull {}

package edu.umd.cs.findbugs.annotations;
@Retention(CLASS)
@Target({FIELD, METHOD, PARAMETER, LOCAL_VARIABLE})
public @interface NonNull {}

package org.eclipse.jdt.annotation;
@Retention(CLASS)
@Target({ TYPE_USE })
public @interface NonNull {}

package org.jetbrains.annotations;
@Retention(CLASS)
@Target({FIELD, METHOD, PARAMETER, LOCAL_VARIABLE})
public @interface NotNull {String value() default "";}

package javax.annotation;
@TypeQualifier
@Retention(RUNTIME)
public @interface Nonnull {
    When when() default When.ALWAYS;
    static class Checker implements TypeQualifierValidator<Nonnull> {
        public When forConstantValue(Nonnull qualifierqualifierArgument,
                Object value) {
            if (value == null)
                return When.NEVER;
            return When.ALWAYS;
        }
    }
}

package org.checkerframework.checker.nullness.qual;
@Retention(RUNTIME)
@Target({TYPE_USE, TYPE_PARAMETER})
@SubtypeOf(MonotonicNonNull.class)
@ImplicitFor(
    types = {
        TypeKind.PACKAGE,
        TypeKind.INT,
        TypeKind.BOOLEAN,
        TypeKind.CHAR,
        TypeKind.DOUBLE,
        TypeKind.FLOAT,
        TypeKind.LONG,
        TypeKind.SHORT,
        TypeKind.BYTE
    },
    literals = {LiteralKind.STRING}
)
@DefaultQualifierInHierarchy
@DefaultFor({TypeUseLocation.EXCEPTION_PARAMETER})
@DefaultInUncheckedCodeFor({TypeUseLocation.PARAMETER, TypeUseLocation.LOWER_BOUND})
public @interface NonNull {}

Tamlık için, @Nullableuygulamalar şunlardır :

package android.support.annotation;
@Retention(CLASS)
@Target({METHOD, PARAMETER, FIELD})
public @interface Nullable {}

package edu.umd.cs.findbugs.annotations;
@Target({FIELD, METHOD, PARAMETER, LOCAL_VARIABLE})
@Retention(CLASS)
public @interface Nullable {}

package org.eclipse.jdt.annotation;
@Retention(CLASS)
@Target({ TYPE_USE })
public @interface Nullable {}

package org.jetbrains.annotations;
@Retention(CLASS)
@Target({FIELD, METHOD, PARAMETER, LOCAL_VARIABLE})
public @interface Nullable {String value() default "";}

package javax.annotation;
@TypeQualifierNickname
@Nonnull(when = When.UNKNOWN)
@Retention(RUNTIME)
public @interface Nullable {}

package org.checkerframework.checker.nullness.qual;
@Retention(RUNTIME)
@Target({TYPE_USE, TYPE_PARAMETER})
@SubtypeOf({})
@ImplicitFor(
    literals = {LiteralKind.NULL},
    typeNames = {java.lang.Void.class}
)
@DefaultInUncheckedCodeFor({TypeUseLocation.RETURN, TypeUseLocation.UPPER_BOUND})
public @interface Nullable {}

Aşağıdaki iki paket yok @Nullable, bu yüzden onları ayrı ayrı listeliyorum; Lombok oldukça sıkıcı @NonNull. Gelen aslında bir olduğunu ve uzunca bir uygulama vardır.javax.validation.constraints@NonNull@NotNull

package lombok;
@Retention(CLASS)
@Target({FIELD, METHOD, PARAMETER, LOCAL_VARIABLE})
public @interface NonNull {}

package javax.validation.constraints;
@Retention(RUNTIME)
@Target({ FIELD, METHOD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
@Constraint(validatedBy = {})
public @interface NotNull {
    String message() default "{javax.validation.constraints.NotNull.message}";
    Class<?>[] groups() default { };
    Class<? extends Payload>[] payload() default {};
    @Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
    @Retention(RUNTIME)
    @Documented
    @interface List {
        NotNull[] value();
    }
}

Destek

Deneyimlerime göre javax.annotation, en azından Eclipse ve Checker Framework tarafından kutunun dışında destekleniyor.

özet

İdeal ek açıklamam java.annotationChecker Framework uygulaması ile sözdizimi olacaktır .

Checker Çerçevesini kullanmak istemiyorsanız javax.annotation( JSR-305 ) şu an için en iyi bahistir.

Checker Çerçevesi satın almak istiyorsanız sadece kullanın org.checkerframework.checker.nullness.qual.


Kaynaklar

  • android.support.annotation itibaren android-5.1.1_r1.jar
  • edu.umd.cs.findbugs.annotations itibaren findbugs-annotations-1.0.0.jar
  • org.eclipse.jdt.annotation itibaren org.eclipse.jdt.annotation_2.1.0.v20160418-1457.jar
  • org.jetbrains.annotations itibaren jetbrains-annotations-13.0.jar
  • javax.annotation itibaren gwt-dev-2.5.1-sources.jar
  • org.checkerframework.checker.nullness.qual itibaren checker-framework-2.1.9.zip
  • lombokdan lomboktaahhütf6da35e4c4f3305ecd1b415e2ab1b9ef8a9120b4
  • javax.validation.constraints itibaren validation-api-1.0.0.GA-sources.jar

7
Bunun dezavantajı, javax.annotationa) ölü bir JSR'ye dayanması, b) ek açıklamaları sağlayan ve korunan bir yapı bulmak zor. Findbugs'tan
robinst

18
Diğer bir nokta da javax.annotation, Java 9 ile ilgili sorunlara neden olmasıdır, çünkü diğer modüller de bu pakette (jax-ws) sınıflar sağlar.
robinst

10
@kevinarpe: Findbugs projesi öldü ve halef projesi Spotbugs bu ek açıklamaları kaldırıyor: github.com/spotbugs/spotbugs/pull/180
robinst

4
Standartlaşacak olan JSR 305 , javax.annotation.NonNullteknik özellikleri kurşun AWOL'a gittiğinden asla tamamlanmadı. Oracle'ın herhangi bir kararı ile ilgisi yoktu.
Mark Reinhold

5
Jsr305.jar'ın kullanılmamasının bir başka nedeni, görünüşe göre Oracle Java ikili lisansını ihlal etmesidir
Flow

91

Ben bir nullness denetleyicisi gibi kusur denetleyicilerini uygulamak için kullanılan tip ek açıklamaları ( JSR-308 ) bir uygulaması olan Checker Çerçeve gibi. Gerçekten başka bir karşılaştırma yapmak için denedim, ama bu uygulama ile mutlu oldum.

Yazılımı sunan gruba bağlı değilim, ama hayranıyım.

Bu sistem hakkında sevdiğim dört şey:

  1. İçin bir kusur denetleyicileri var nullness (@Nullable), ancak aynı zamanda olanlar vardır değişmezlik ve interning (ve diğerleri). Ben birincisini (nullness) kullanıyorum ve ikincisini (değişmezlik / IGJ) kullanmaya çalışıyorum. Üçüncüsünü deniyorum, ama uzun vadede kullanma konusunda henüz emin değilim. Diğer damaların genel kullanışlılığına henüz ikna olmadım, ancak çerçevenin kendisinin çeşitli ek ek açıklamaları ve damaları uygulamak için bir sistem olduğunu bilmek güzel.

  2. Nullness denetimi için varsayılan ayar iyi çalışıyor: Sigara null adlı halk (NNEL) hariç. Temel olarak bu, denetleyicinin yerel değişkenler dışında varsayılan olarak @NonNull türünde olduğu gibi herhing (örnek değişkenler, yöntem parametreleri, genel türler, vb.) Belgelere göre:

    NNEL varsayılanı, kodunuzdaki en az sayıda açık ek açıklamaya yol açar.

    NNEL sizin için işe yaramıyorsa, bir sınıf veya yöntem için farklı bir varsayılan ayarlayabilirsiniz.

  3. Bu çerçeve, açıklamalarınızı bir yoruma ekleyerek çerçeveye bağımlılık yaratmadan kullanmanıza olanak tanır : ör./*@Nullable*/ . Bu güzel çünkü bir kitaplığa veya paylaşılan koda ek açıklama ekleyebilir ve kontrol edebilirsiniz, ancak yine de bu kütüphaneyi / paylaşılan kodlamayı çerçeveyi kullanmayan başka bir projede kullanabilirsiniz. Bu güzel bir özellik. Şimdi tüm projelerim üzerinde Checker Çerçevesini etkinleştirme eğilimim olmasına rağmen kullanmaya alıştım.

  4. Çerçevede, saplama dosyaları kullanarak boşluk nedeniyle zaten açıklanmamış olan kullandığınız API'lara ek açıklama koymanın bir yolu vardır .


3
Harika görünüyor ve kullanmak istiyorum, ama kullanamıyorum. Neden GPL? Bunun yerine LGPL olamaz mı?
Burkhard

13
SSS'ye göre : "Ek açıklamalar gibi kendi programınıza dahil etmek isteyebileceğiniz kodlar için daha izin verilen MIT Lisansı geçerlidir."
seanf

1
Bağlantılar şu anda bozuk. Ancak Checker Framework'ü kullanma önerisi için +1.
Paul Wagland

1
Değişmezlik denetleyicilerinin son sürümde bırakılması üzücü.
Franklin Yu

1
Checker Çerçevesi ayrıca Oracle Java Tutorials'ta da önerilmektedir .
Quazi Irfan

55

IntelliJ olanını kullanıyorum, çünkü çoğunlukla NPE üretebilecek şeyleri IntelliJ ile işaretlemekle ilgileniyorum. JDK'da standart bir ek açıklama olmamasının sinir bozucu olduğunu kabul ediyorum. Ekleme konuşması var, Java 7'ye girebilir. Bu durumda seçim yapmak için bir tane daha olacak!


68
Güncelleme: IntelliJ artık kod vurgulama için yukarıdaki ek açıklamaların tümünü desteklediğinden, artık IntelliJ'in ek açıklamalarıyla sınırlı değilsiniz: blogs.jetbrains.com/idea/2011/03/…
Daniel Alexiuc

31
Eclipse Juno da öyle!
jFrenetic

5
javax.annotation.Nonnulldaha yaygın kabul görüyor, değil mi?
Martin

1
@DanielAlexiuc Ne yazık ki, bunları çalışma zamanı kontrolleri için kullanmıyor, bu yüzden JetBrains olanlarını kullanmanın hala bir faydası var ...
Trejkaz

4
@Trejkaz 2016.3'ten beri tüm bunlar için çalışma zamanı kontrolleri oluşturur.
Karol S

32

Göre Java 7 özellikleri listesinde JSR-308 tipi ek açıklamaları bile belirtilmeyen Java 8. JSR-305 ek açıklamaları için ertelenir.

Ekte JSR-305'in durumu hakkında biraz bilgi varEn son JSR-308 taslağının . Bu, JSR-305 ek açıklamalarının terk edilmiş gibi göründüğü gözlemi içerir. JSR-305 sayfası da "etkin değil" olarak gösterir.

Bu arada, pragmatik cevap, en yaygın kullanılan araçlar tarafından desteklenen ek açıklama türlerini kullanmak ... ve durum değişirse bunları değiştirmeye hazır olmaktır.


Aslında, JSR-308 herhangi bir ek açıklama türü / sınıfı tanımlamaz ve kapsam dışı olduğunu düşünüyorlar. (JSR-305'in varlığı göz önüne alındığında haklılar).

Ancak, JSR-308 gerçekten Java 8'e dönüştürüyor gibi görünüyorsa, JSR-305'e olan ilgi canlanırsa beni şaşırtmaz. AFRİK, JSR-305 ekibi çalışmalarını resmi olarak terk etmedi. Onlar sadece 2 + yıldır sessiz olmuştur.

İlginçtir Bill Pugh (JSR-305'in teknik lideri) FindBugs'un arkasındaki adamlardan biri.


4
@pst - şu anki zaman Java 8'in Eylül 2013'te genel sürümüne geçmesi - infoq.com/news/2012/04/jdk-8-milestone-release-dates
Stephen C

2
Bu şimdi Mart 2014'e düştü - openjdk.java.net/projects/jdk8 . JSR 308, yapı M7'de bulunur ("104 - Java Türlerine İlişkin Ek Açıklamalar" konusuna bakın).
Stephen C

28

Android projeleri için android.support.annotation.NonNullve kullanmalısınız android.support.annotation.Nullable. Bunlar ve Android'e özgü diğer yararlı ek açıklamalar Destek Kitaplığı'nda bulunabilir .

Http://tools.android.com/tech-docs/support-annotations adresinden :

Destek kitaplığının kendisi de bu ek açıklamalarla açıklanmıştır, bu nedenle destek kitaplığının bir kullanıcısı olarak Android Studio kodunuzu zaten kontrol edecek ve bu ek açıklamalara dayanarak olası sorunları işaretleyecektir.


3
Bu öneri için gerekçe sunmak yararlı olacaktır.
kayısı

2
tools.android.com/tech-docs/support-annotations "Destek kitaplığının kendisi de bu ek açıklamalarla açıklanmıştır, bu nedenle destek kitaplığının bir kullanıcısı olarak Android Studio kodunuzu kontrol edecek ve bu ek açıklamalara dayalı olası sorunları işaretleyecektir ."
James Wald

3
BTW Android Studio javax.annotation.*ek açıklamalarla
jsr305'i

19

Herhangi biri yalnızca IntelliJ sınıflarını arıyorsa: bunları maven deposundan alabilirsiniz.

<dependency>
    <groupId>org.jetbrains</groupId>
    <artifactId>annotations</artifactId>
    <version>15.0</version>
</dependency> 

Intellij'in uyarı göndermesine neden olan bu, evet.
Click Olumlu oy

Mevcut sürüm (05/2017 itibarıyla) 15.0
BamaPookie

Haklısın. Sürümü güncelledim. Tahminimce çok fazla değişmedi.
Bruno Eberhard

JetBrains ek açıklamalarının çalışma zamanı için saklanmadığını unutmayın, bu nedenle örneğin Guice @Nullable desteği onunla çalışmaz.
Peter Major

18

JSR305 ve FindBugs aynı kişi tarafından yazılmıştır. Her ikisi de kötü bir şekilde korunur, ancak standart olarak alınır ve tüm büyük IDE'ler tarafından desteklenir. İyi haber şu ki, olduğu gibi iyi çalışıyorlar.

@Nonnull öğesini varsayılan olarak tüm sınıflara, yöntemlere ve alanlara nasıl uygulayacağınız aşağıda açıklanmıştır. Bkz. Https://stackoverflow.com/a/13319541/14731 ve https://stackoverflow.com/a/9256595/14731

  1. Tanımlamak @NotNullByDefault
import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import javax.annotation.Nonnull;
import javax.annotation.meta.TypeQualifierDefault;


    /**
     * This annotation can be applied to a package, class or method to indicate that the class fields,
     * method return types and parameters in that element are not null by default unless there is: <ul>
     * <li>An explicit nullness annotation <li>The method overrides a method in a superclass (in which
     * case the annotation of the corresponding parameter in the superclass applies) <li> there is a
     * default parameter annotation applied to a more tightly nested element. </ul>
     * <p/>
     * @see https://stackoverflow.com/a/9256595/14731
     */
    @Documented
    @Nonnull
    @TypeQualifierDefault(
    {
        ElementType.ANNOTATION_TYPE,
        ElementType.CONSTRUCTOR,
        ElementType.FIELD,
        ElementType.LOCAL_VARIABLE,
        ElementType.METHOD,
        ElementType.PACKAGE,
        ElementType.PARAMETER,
        ElementType.TYPE
    })
    @Retention(RetentionPolicy.RUNTIME)
    public @interface NotNullByDefault
    {
    }

2. Ek açıklamayı her pakete ekleyin: package-info.java

@NotNullByDefault
package com.example.foo;

GÜNCELLEME : 12 Aralık 2012 itibariyle JSR 305 "Hareketsiz" olarak listelenmiştir. Belgelere göre:

Yürütme Komitesi tarafından "hareketsiz" olarak oylanan veya doğal ömrünün sonuna gelmiş bir JSR.

Görünüşe JSR 308 olan JDK 8 içine yapım ve JSR @NotNull tanımlamıyor rağmen, beraberindeki Checkers Frameworkyapar. Bu yazı yazılırken, Maven eklentisi bu hata nedeniyle kullanılamaz: https://github.com/typetools/checker-framework/issues/183


2
Maven için showtopper sorunu düzeltildi. Yani bu yine bir seçenek olmalı.
Marc von Renteln

Maven yoluyla FindBugs kullanıyorum, IDE'm tarafından hiçbir şey yapılmıyor, bu IDE'ye özgü ek açıklamalardan kaçınıyor, ne önerirsiniz?
Christophe Roussy

@ChristopheRoussy Sorunuz IDE'ye özgü. Lütfen ayrı bir soru açın.
Gili

15

Statik analiz ve çalışma zamanı analizi arasında ayrım yapın. Dahili öğeler için statik analizi ve kodunuzun genel sınırları için çalışma zamanı analizini kullanın.

Boş olmaması gereken şeyler için:

  • Çalışma zamanı denetimi: "if (x == null) ..." (sıfır bağımlılık) veya @ javax.validation.NotNull (fasulye doğrulama ile) veya @ lombok.NonNull (düz ve basit) veya guavas Preconditions.checkNotNull (.. .)

    • Yöntem döndürme türleri için İsteğe Bağlı seçeneğini kullanın (yalnızca). Java8 veya Guava.
  • Statik kontrol: @NonNull ek açıklaması kullanın

  • Uygun olduğu yerde, sınıfta veya paket düzeyinde @ ... NonnullByDefault ek açıklamaları kullanın. Bu ek açıklamaları kendiniz oluşturun (örneklerin bulunması kolaydır).
    • Başka, @ kullanın ... NPE'leri önlemek için yöntem döndürür CheckForNull

Bu en iyi sonucu vermelidir: IDE'deki uyarılar, Findbugs ve checkerframework hataları, anlamlı çalışma zamanı istisnaları.

Statik kontrollerin olgunlaşmasını beklemeyin, isimlendirmeleri standart değildir ve farklı kütüphaneler ve IDE'ler onlara farklı davranır, görmezden gelir. JSR305 javax.annotations. * Sınıfları standart gibi görünür, ancak değildir ve Java9 + ile bölünmüş paketlere neden olur.

Bazı notlar açıklamaları:

  • Javab + 'daki diğer modüllerle çakıştığında, Oracle lisansını da ihlal etmesi için Findbugs / spotbugs / jsr305 ek açıklamaları javax.validation. *
  • Spotbugs ek açıklamaları hala derleme sırasında jsr305 / findbugs ek açıklamalarına bağlıdır ( https://github.com/spotbugs/spotbugs/issues/421 yazılırken )
  • jetbrains @NotNull adı @ javax.validation.NotNull ile çakışıyor.
  • statik kontrol için jetbrains, eclipse veya checkersframework ek açıklamaları javax'a göre avantajlıdır. Java9 ve sonraki sürümlerde diğer modüllerle çakışmadıkları ek açıklamalar
  • Nulllable, Findbugs / Spotbugs için sizin (veya IDE'nizin) ne anlama geldiğini kastetmez. Findbugs bunu görmezden gelecek (üyelerde). Üzgün, ama gerçek ( https://sourceforge.net/p/findbugs/bugs/1181 )
  • Bir IDE dışında statik kontrol için 2 ücretsiz araç vardır: Spotbugs (eski adıyla Findbugs) ve checkersframework.
  • Eclipse kütüphanesinde @NonNullByDefault, jsr305 sadece @ParametersAreNonnullByDefault vardır. Bunlar sadece bir paketteki (veya sınıftaki) her şeye taban ek açıklamaları uygulayan kolaylık sarmalayıcılarıdır, kolayca kendiniz oluşturabilirsiniz. Bu paket üzerinde kullanılabilir. Bu, oluşturulan kodla (ör. Lombok) çakışabilir.
  • Başkalarıyla paylaştığınız kütüphaneler için lombok'u dışa aktarılmış bir bağımlılık olarak kullanmaktan kaçınılmalıdır, daha az geçişli bağımlılıklar daha iyi
  • Bean doğrulama çerçevesinin kullanılması güçlüdür, ancak yüksek ek yük gerektirir, bu nedenle manuel olarak boş denetim yapılmasını önlemek için bu aşırıya kaçar.
  • Alanlar ve yöntem parametreleri için İsteğe bağlı kullanımı tartışmalıdır (bu konudaki makaleleri kolayca bulabilirsiniz)
  • Android null ek açıklamalar Android destek kitaplığının bir parçasıdır, diğer birçok sınıfla birlikte gelir ve diğer ek açıklamalarla / araçlarla iyi oynamazlar

Java9'dan önce, bu benim tavsiyem:

// file: package-info.java
@javax.annotation.ParametersAreNonnullByDefault
package example;


// file: PublicApi
package example;

public interface PublicApi {

    Person createPerson(
        // NonNull by default due to package-info.java above
        String firstname,
        String lastname);
}

// file: PublicApiImpl
public class PublicApiImpl implements PublicApi {
    public Person createPerson(
            // In Impl, handle cases where library users still pass null
            @Nullable String firstname, // Users  might send null
            @Nullable String lastname // Users might send null
            ) {
        if (firstname == null) throw new IllagalArgumentException(...);
        if (lastname == null) throw new IllagalArgumentException(...);
        return doCreatePerson(fistname, lastname, nickname);
    }

    @NonNull // Spotbugs checks that method cannot return null
    private Person doCreatePerson(
             String firstname, // Spotbugs checks null cannot be passed, because package has ParametersAreNonnullByDefault
             String lastname,
             @Nullable String nickname // tell Spotbugs null is ok
             ) {
         return new Person(firstname, lastname, nickname);
    }

    @CheckForNull // Do not use @Nullable here, Spotbugs will ignore it, though IDEs respect it
    private Person getNickname(
         String firstname,
         String lastname) {
         return NICKNAMES.get(firstname + ':' + lastname);
    }
}

Null olabilecek bir yöntem parametresi silindiğinde (yazma sırasında Spotbugs'un 3.1 sürümü) Spotbugs'ın uyarı oluşturmasının bir yolu olmadığını unutmayın. Belki dama işi bunu yapabilir.

Ne yazık ki bu ek açıklamalar, keyfi çağrı sitelerine sahip bir kütüphanenin genel bir yöntemi ile her çağrı alanının bilinebildiği halka açık olmayan yöntemler arasında ayrım yapmaz. Bu nedenle, "null öğesinin istenmeyen olduğunu belirtin, ancak yine de null iletilmek için hazırlanın" tek bir bildiride mümkün değildir, dolayısıyla yukarıdaki örneğin arayüz ve uygulama için farklı ek açıklamaları vardır.

Bölünmüş arayüz yaklaşımının pratik olmadığı durumlarda, aşağıdaki yaklaşım bir uzlaşmadır:

        public Person createPerson(
                @NonNull String firstname,
                @NonNull String lastname
                ) {
            // even though parameters annotated as NonNull, library clients might call with null.
            if (firstname == null) throw new IllagalArgumentException(...);
            if (lastname == null) throw new IllagalArgumentException(...);
            return doCreatePerson(fistname, lastname, nickname);
        }

Bu, istemcilerin boş değerleri (doğru kod yazarak) geçmemelerine yardımcı olurken, yararlı hatalar döndürür.


Ben sadece şimdi bu cevabı buldum, ama @tkruse, nerede buldum: "Eclipse jdt ek açıklamaları statik yöntem döndürme ve diğer bazı durumlar için geçerli değil"? (ilk kısım doğru değil, ikinci oldukça belirsiz :)).
Stephan Herrmann

@StephanHerrmann: Hatırlayamıyorum. Mermi noktasını çıkardım.
tkruse

12

Tutulmanın kendi ek açıklamaları da vardır.

org.eclipse.jdt.annotation.NonNull

Bkz. http://wiki.eclipse.org/JDT_Core/Null_Analysis adresine bakın.


Eclipse 3.8 (Juno) 'dan entegre edilecek gibi görünüyor, bu da Eclipse'yi IntelliJ ile aynı hizaya getirecek. Ayrıca kendi Null ek açıklamalarınızı (örn. Javax.annotation.Nonnull) yapılandırmanıza izin vermeli ve NotNull'u varsayılan olarak ayarlama seçeneğine sahiptir.
Motti Strom

11

Java Doğrulama API'sının ( javax.validation.constraints.*) @Nullablebir statik analiz bağlamında çok değerli olan bir ek açıklama ile gelmediğine dikkat edin . Bu, Java'daki ilkel olmayan herhangi bir alan için varsayılan olduğu için çalışma zamanı fasulye doğrulaması için anlamlıdır (yani, doğrulamak / uygulamak için hiçbir şey yoktur). Belirtilen amaçlar için alternatiflere doğru ağırlık vermelidir.


7

Maalesef, JSR 308buradaki yerel Null Değeri önerisinden daha fazla değer eklemeyeceğiz

Java 8tek bir varsayılan ek açıklama veya kendi Checkerçerçevesi ile gelmez . Find-bugs ya da JSR 305bu JSR, çoğunlukla akademik takımlardan oluşan küçük bir grup tarafından zayıf bir şekilde korunur.

Arkasında hiçbir ticari güç yok, bu yüzden ŞİMDİ JSR 308başlıyor EDR 3(Erken Taslak İnceleme at JCP) ŞİMDİ, Java 86 aydan daha kısa sürede gönderilmesi gerekiyor: -O btw'ye benzer 310. ama bunun aksine 308 Oracle, zararını en aza indirmek için kurucularından uzaklaştı ve Java Platformuna yapacağını söyledi.

Arkasında olanlar gibi her proje, satıcı ve akademik sınıf Checker FrameworkveJSR 308 kendi özel denetçi ek açıklama yaratacaktır.

Birkaç popüler uzlaşma bulunana ve belki Java 9veya 10, veya Apache Commonsveya Google Guava;-) gibi çerçevelerle eklenene kadar kaynak kodunu önümüzdeki yıllar boyunca uyumsuz hale getirmek


7

Android

Bu cevap Android'e özeldir. Android adlı destek paketi var support-annotations. Bu sağlar onlarca ait Android belirli ek açıklamaları ve ayrıca sağlayan ortak olanları gibi NonNull, Nullablevb

Eklemek için destek-ek açıklamalar paketi, sizin build.gradle aşağıdaki bağımlılık ekleyin:

compile 'com.android.support:support-annotations:23.1.1'

ve sonra şunu kullanın:

import android.support.annotation.NonNull;

void foobar(@NonNull Foo bar) {}

5

Bunun yukarı yönde sıralanmasını beklerken (Java 8?), Sadece kendi yerel proje @NotNullve @Nullableek açıklamalarınızı tanımlayabilirsiniz . Bu, varsayılan olarak javax.validation.constraints bulunmayan Java SE ile çalışmanız durumunda da yararlı olabilir .

import java.lang.annotation.*;

/**
 * Designates that a field, return value, argument, or variable is
 * guaranteed to be non-null.
 */
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.LOCAL_VARIABLE})
@Documented
@Retention(RetentionPolicy.CLASS)
public @interface NotNull {}

/**
 * Designates that a field, return value, argument, or variable may be null.
 */
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.LOCAL_VARIABLE})
@Documented
@Retention(RetentionPolicy.CLASS)
public @interface Nullable {}

Kuşkusuz bu, büyük ölçüde dekoratif veya geleceğe yönelik amaçlar için olacaktır, çünkü yukarıdakiler açıkça bu açıklamaların statik analizi için kendi başına herhangi bir destek eklemez.


4

Eğer android için gelişmekte ediyorsanız, konum biraz Eclipse bağlı (düzenleme: Artık yok yazma anda) kendi açıklamaları var. Eclipse 3.8+ (Juno) sürümüne dahildir, ancak varsayılan olarak devre dışıdır.

Tercihler> Java> Derleyici> Hatalar / Uyarılar> Boş analiz (alt kısımdaki daraltılabilir bölüm) öğesinden etkinleştirebilirsiniz.

"Ek açıklama tabanlı boş analizi etkinleştir" seçeneğini işaretleyin

http://wiki.eclipse.org/JDT_Core/Null_Analysis#Usage ayarlarla ilgili öneriler içeriyor. Ancak, çalışma alanınızda (facebook SDK gibi) harici projeleriniz varsa, bu önerileri karşılamayabilirler ve muhtemelen her bir SDK güncellemesi ;-) ile düzeltmek istemezsiniz.

Kullanırım:

  1. Boş işaretçi erişimi: Hata
  2. Boş belirtimin ihlali: Hata (1. noktaya bağlı)
  3. Potansiyel boş gösterici erişimi: Uyarı (aksi takdirde facebook SDK'sında uyarı olur)
  4. Boş ek açıklamalar ile boş çıkarım arasında çatışma: Uyarı (3. noktaya bağlı)

4
Tutulmaya mı bağlı? Doğru değil.
dcow

1
@DavidCowden Android geliştirme desteği sunan IntelliJ IDEA, sanırım AndroidStudio'nun kullanıma sunulmasından bir süre önce mevcuttu.
Brirtiņš Briedis

@ MārtiņšBriedis evet, bu doğru. Sanırım demek istedin @chaqke.
dcow

android ve intellij'in ayrı ek açıklamaları olduğunu ve java resmi ek açıklamaları içerene kadar muhtemelen bu şekilde kalacağını belirtmek gerekir. bunlar, tutulmanın eklipse ile ek açıklamalarını kullanma talimatlarıdır.
chaqke

Eclipse ile hiç bağlanmadı. İstediğiniz herhangi bir IDE'yi kullanabilirsiniz.
DennisK

4

Büyük bir proje üzerinde çalışıyorsanız, kendi @Nullable ve / veya @NotNullek açıklamalarınızı oluşturmakta daha iyi olabilirsiniz .

Örneğin:

@java.lang.annotation.Documented
@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.CLASS)
@java.lang.annotation.Target({java.lang.annotation.ElementType.FIELD,
                              java.lang.annotation.ElementType.METHOD,    
                              java.lang.annotation.ElementType.PARAMETER,
                              java.lang.annotation.ElementType.LOCAL_VARIABLE})
public @interface Nullable 
{
}

Doğru saklama politikasını kullanırsanız ek açıklamalar çalışma zamanında kullanılamaz . Bu açıdan bakıldığında, bu sadece içsel bir şeydir.

Bu katı bir bilim olmasa da, bunun için bir sınıf kullanmak en mantıklı .

  • Bu içsel bir şeydir. (işlevsel veya teknik bir etkisi yoktur)
  • Birçok çok kullanımları ile.
  • IntelliJ gibi IDE'ler özel @Nullable/ @NotNullek açıklamaları destekler .
  • Çoğu çerçeve kendi dahili versiyonunu kullanmayı tercih eder.

Ek Sorular (yorumlara bakın):

IntelliJ'de bunu nasıl yapılandırabilirim?

IntelliJ durum çubuğunun sağ alt köşesindeki "polis memuru" nu tıklayın. Açılır pencerede "Denetimleri yapılandır" ı tıklayın. Sonraki ... ek açıklamaları yapılandır


1
Tavsiyeni denedim, ama tarafından çağrılan ideahakkında hiçbir şey söylemedivoid test(@NonNull String s) {}test(null);
user1244932

3
@ user1244932 Şunu mu demek istediniz: IntelliJ IDEA? Statik analiz için kullandığı sıfırlanabilirlik ek açıklamalarını yapılandırabilirsiniz. Tam olarak nerede olduğunu bilmiyorum, ancak bunları tanımlamak için bir yer "Dosya> Ayarlar> Oluşturma, Yürütme, Dağıtım> Derleyici" ve "Ek açıklamaları yapılandır ..." düğmesinde.
Adowrath

Hala arıyorsanız, @ user1244932 ekran görüntüsüne bakın.
bvdb

3

Burada zaten çok fazla cevap var, ama (a) 2019, ve hala "standart" Nullableve (b) başka cevap yok Kotlin'e atıfta bulunmuyor.

Kotlin'e referans önemlidir, çünkü Kotlin Java ile% 100 birlikte çalışabilir ve çekirdek bir Boş Güvenlik özelliğine sahiptir. Java kitaplıklarını çağırırken, Kotlin araçlarının bir Java API'sinin kabul edip edemeyeceğini bildirmek için bu ek açıklamalardan yararlanabilir null.

Bildiğim kadarıyla, NullableKotlin ile uyumlu tek paketler org.jetbrains.annotationsve android.support.annotation(şimdi androidx.annotation). İkincisi sadece Android ile uyumludur, bu nedenle Android olmayan JVM / Java / Kotlin projelerinde kullanılamaz. Ancak, JetBrains paketi her yerde çalışır.

Dolayısıyla, Android ve Kotlin'de de çalışması gereken (ve Android Studio ve IntelliJ tarafından desteklenecek) Java paketleri geliştirirseniz, en iyi seçiminiz muhtemelen JetBrains paketidir.

Uzman:

<dependency>
    <groupId>org.jetbrains</groupId>
    <artifactId>annotations-java5</artifactId>
    <version>15.0</version>
</dependency>

Gradle:

implementation 'org.jetbrains:annotations-java5:15.0'


3

Java 8'de bunu yapmanın başka bir yolu var. Ben ihtiyacım olanı gerçekleştirmek için 2 şey yapıyorum:

  1. Null olabilecek alanları şununla sararak null olabilecek alanları türlerle açık hale getirme java.util.Optional
  2. Tüm null olmayan alanların inşaat sırasında boş olmadığını kontrol etme java.util.Objects.requireNonNull

Misal:

import static java.util.Objects.requireNonNull;

public class Role {

  private final UUID guid;
  private final String domain;
  private final String name;
  private final Optional<String> description;

  public Role(UUID guid, String domain, String name, Optional<String> description) {
    this.guid = requireNonNull(guid);
    this.domain = requireNonNull(domain);
    this.name = requireNonNull(name);
    this.description = requireNonNull(description);
  }

Benim sorum şu ki, java 8 kullanırken açıklama eklememiz gerekiyor mu?

Düzenleme: Daha sonra bazı Optionalargümanlarda kullanmak için kötü bir uygulama düşündüğünü öğrendim , artıları ve eksileri ile iyi bir tartışma var Neden Java 8'in isteğe bağlı argümanlarda kullanılmamalıdır

Bağımsız seçeneklerde İsteğe bağlı kullanılmasının önerilmemesi nedeniyle alternatif seçenek, 2 kurucuya ihtiyacımız var:

  //Non null description
  public Role(UUID guid, String domain, String name, String description) {
        this.guid = requireNonNull(guid);
        this.domain = requireNonNull(domain);
        this.name = requireNonNull(name);

        // description will never be null
        requireNonNull(description);

        // but wrapped with an Optional
        this.description = Optional.of(description);
      }

  // Null description is assigned to Optional.empty
  public Role(UUID guid, String domain, String name) {
        this.guid = requireNonNull(guid);
        this.domain = requireNonNull(domain);
        this.name = requireNonNull(name);
        this.description = Optional.empty();
      }

Hala 4 resmi parametre için @NotNull ek açıklamasına ihtiyaç duyduğunuzu söyleyebilirim, böylece statik analiz denetleyicileri hiçbirinin boş olmaması gerektiğini niyetinizi bilir. Java dilinde henüz bunu uygulayan hiçbir şey yok. Defansif olarak programlıyorsanız, açıklamanın boş olmadığını da kontrol etmelisiniz.
jaxzin

2
Hala bu kodu yazabilirsiniz: new Role(null,null,null,null);. Ek açıklamalarla IDE'm ve statik analizim, null değerinin bu parametrelere aktarılamayacağı konusunda uyarır. O olmadan ben kodu çalıştırmak kadar öğrenemiyorum. Ek açıklamaların değeri budur.
jaxzin

2
Ayrıca, geliştiricilerin tercih ettikleri herhangi bir IDE veya metin düzenleyicisini kullanabileceği ortamlardayım, bu birbirini dışlayan değil. Daha sonra maven-pmd-eklentisini ve / veya SonarQube'u, örneğin çekme isteklerinde birleştirme öncesi kod kalitesi konularını teşvik etmek ve vurgulamak ve hatta birleştirmek için oluşturma sürecine entegre ediyoruz.
jaxzin

2
İsteğe bağlı bir yöntem bağımsız değişkeni veya özel alan olarak kullanılması amaçlanmamıştır. Örneğin bakınız: stuartmarks.wordpress.com/2016/09/27/vjug24-session-on-optional
asylias

1
@assylias evet, daha sonra öğrendim, bize bir şey satın almayacağı için tavsiye edilmediğini söylüyorlar, kesinlikle rasyonellerini anlayabiliyorum. Bu durumda buraya koydum, bir argüman description null değil ve istemci kodu boş bir String geçirebilir, ancak birçok durumda Dize ve boş Dize ayırmak ve bir değeri olmayan kullanışlı olabilir. Yorumun için teşekkürler. Cevabı güncelleyeceğim.
Mozart Brocchini

2

Güneşin artık kendi güneşi yok mu? Bu nedir:
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-com.sun/istack/com.sun.istack.internal.htm

Bu, son birkaç yıldır kullandığım tüm Java sürümleriyle paketlenmiş gibi görünüyor.

Düzenleme: Aşağıdaki yorumlarda belirtildiği gibi, muhtemelen bunları kullanmak istemezsiniz. Bu durumda, oyum IntelliJ jetbrains ek açıklamaları için!


10
Ne olduğu hakkında hiçbir fikrim yok, ancak paket adı genel kullanıma yönelik OLMAYAN BÜYÜK BİR CLUE olmalıdır.
Stephen C

3
Genellikle com.sun ad alanındaki sınıfları dahili olarak kullanmaktan kaçınır; doğrudan kullanım için değil; ve gelecekteki mevcudiyetleri veya davranışları için hiçbir garanti verilmeksizin. Doğrudan com.sun artefaktını kullanmak için gerçekten sağlam bir kasaya sahip olmak gerekir.
luis.espinal

artı böyle kötü HTML biçiminde görüntülenen bir şey (üst üste Java2s.com) size bazı kırmızı bayraklar vermelidir :)
vermelidir luis.espinal

2

IntelliJ ile ilgili güzel şeylerden biri, ek açıklamalarını kullanmanıza gerek olmamasıdır. Kendinizinkini yazabilir veya istediğiniz diğer araçlardan birini kullanabilirsiniz. Tek bir türle bile sınırlı değilsiniz. Farklı @NotNull ek açıklamaları kullanan iki kütüphane kullanıyorsanız, IntelliJ'e her ikisini de kullanmasını söyleyebilirsiniz. Bunu yapmak için, "Denetimleri Yapılandır" a gidin, "Sabit Koşullar ve İstisnalar" denetlemesine tıklayın ve "Denetimleri yapılandır" düğmesine basın. Nullness Checker'ı elimden geldiğince kullanıyorum, bu nedenle IntelliJ'i bu ek açıklamaları kullanacak şekilde ayarladım, ancak istediğiniz diğer araçlarla çalışmasını sağlayabilirsiniz. (Diğer araçlar hakkında hiçbir fikrim yok çünkü IntelliJ'in denetimlerini yıllardır kullanıyorum ve onları seviyorum.)


1

Başka bir seçenek, ANTLR 4 ile sağlanan ek açıklamalardır. Çekme İsteği # 434'ün ardından , @NotNullve @Nullableek açıklamaları içeren yapı, derleme zamanı hataları ve / veya bu özelliklerden birinin yanlış kullanılması durumunda uyarılar üreten bir ek açıklama işlemcisi içerir (örneğin, her ikisi de aynı öğeye @Nullableuygulanır veya ilkel türdeki öğeye uygulanırsa). Ek açıklama işlemcisi, yazılım geliştirme işlemi sırasında, bu ek açıklamaların uygulanmasıyla iletilen bilgilerin, yöntem mirası da dahil olmak üzere doğru olduğuna dair ek güvence sağlar.


1

Uygulamanızı Spring Framework kullanarak oluşturuyorsanız , aşağıdaki bağımlılıkla paketlenmiş Fasulye Doğrulamasındanjavax.validation.constraints.NotNull gelenleri kullanmanızı öneririm :

    <dependency>
        <groupId>javax.validation</groupId>
        <artifactId>validation-api</artifactId>
        <version>1.1.0.Final</version>
    </dependency>

Bu ek açıklamanın ana avantajı, Spring'in hem yöntem parametreleri hem de açıklamalı sınıf alanları için destek sağlamasıdır javax.validation.constraints.NotNull. Desteği etkinleştirmek için tek yapmanız gereken:

  1. Fasulye validasyonu için api kavanozunu jsr-303 / jsr-349 ek açıklamalarının (Hibernate Validator 5.x bağımlılığı ile birlikte gelir) doğrulayıcısının uygulanmasıyla tedarik edin:

    <dependency>
        <groupId>javax.validation</groupId>
        <artifactId>validation-api</artifactId>
        <version>1.1.0.Final</version>
    </dependency>
    <dependency>
        <groupId>org.hibernate</groupId>
        <artifactId>hibernate-validator</artifactId>
        <version>5.4.1.Final</version>
    </dependency>
  2. Spring bağlamına MethodValidationPostProcessor sağlayın

      @Configuration
      @ValidationConfig
      public class ValidationConfig implements MyService {
    
            @Bean
            public MethodValidationPostProcessor providePostProcessor() {
                  return new MethodValidationPostProcessor()
            }
      }
  3. Sonunda Spring'le derslerinize not eklersiniz org.springframework.validation.annotation.Validatedve doğrulama Spring tarafından otomatik olarak yapılır.

Misal:

@Service
@Validated
public class MyServiceImpl implements MyService {

  @Override
  public Something doSomething(@NotNull String myParameter) {
        // No need to do something like assert myParameter != null  
  }
}

DoSomething yöntemini çağırmayı denediğinizde ve parametre değeri olarak null değerini ilettiğinizde, spring (HibernateValidator aracılığıyla) atar ConstraintViolationException. Burada manevra yapmaya gerek yok.

Dönüş değerlerini de doğrulayabilirsiniz.

javax.validation.constraints.NotNullFasulye Validasyon Çerçevesi için gelen bir diğer önemli fayda , şu anda hala geliştirilmesidir ve yeni sürüm 2.0 için yeni özelliklerin planlanmasıdır.

Ne olmuş @Nullable? Fasulye Validasyonu 1.1'de böyle bir şey yoktur. Eh, @NotNullaçıklama ile değil her şeyden daha kullanmaya karar verirseniz @NonNulletkili bir şekilde "geçersiz" olduğunu, bu nedenle @Nullableaçıklama işe yaramaz olduğunu savunabiliriz.


1
Lütfen kullanmayın. Statik kod analizi DEĞİL, çalışma zamanı doğrulaması için kullanılır. Ayrıntılar için justsomejavaguy.blogspot.com/2011/08/… adresine bakın. Kaynak: @ luis.espinal tarafından 219 oyla SİLİNDİĞİNİ SİLİNDİ.
koppor

@koppor: Katılmıyorum. Bu kullanım için tasarlanmamışsa, Spring neden çalışma zamanında halleder? Ayrıca Fasulye doğrulama çerçevesi, çalışma zamanında Context nesnesine (şu anda açıklamalı / onaylanmış örnek) erişmesine izin verdiği için yalnızca çalışma zamanı analizi için ek açıklamalar oluşturmanıza olanak tanır.
walkeros

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.