java - मैं किस @NotNull जावा एनोटेशन का उपयोग करना चाहिए?




nullpointerexception annotations (13)

मैं अपने कोड को और अधिक पठनीय बनाने के साथ-साथ न्यूलपॉन्टर एक्सेप्शन से बचने के लिए आईडीई कोड निरीक्षण और / या स्थैतिक कोड विश्लेषण (FindBugs और सोनार) जैसे टूलिंग का उपयोग करना चाहता हूं। कई टूल एक दूसरे के @NonNull / @Nonnull / @Nonnull एनोटेशन के साथ असंगत प्रतीत होते हैं और मेरे कोड में उन सभी को सूचीबद्ध करने के लिए भयानक @Nonnull । कोई सुझाव कौन सा 'सर्वश्रेष्ठ' है? यहां मिले समकक्ष एनोटेशन की सूची यहां दी गई है:

  • javax.validation.constraints.NotNull
    रनटाइम सत्यापन के लिए बनाया गया, स्थैतिक विश्लेषण नहीं।
    documentation

  • edu.umd.cs.findbugs.annotations.NonNull
    Findbugs स्थिर विश्लेषण द्वारा उपयोग किया जाता है और इसलिए सोनार (अब Sonarqube )
    documentation

  • javax.annotation.Nonnull
    यह Findbugs के साथ भी काम कर सकता है, लेकिन JSR-305 निष्क्रिय है। (यह भी देखें: जेएसआर 305 की स्थिति क्या है? ) source

  • org.jetbrains.annotations.NotNull
    स्थिर विश्लेषण के लिए IntelliJ IDEA IDE द्वारा उपयोग किया जाता है।
    documentation

  • lombok.NonNull
    प्रोजेक्ट लंबोक में कोड पीढ़ी को नियंत्रित करने के लिए प्रयुक्त होता है।
    प्लेसहोल्डर एनोटेशन क्योंकि कोई मानक नहीं है।
    source , documentation

  • android.support.annotation.NonNull
    समर्थन-एनोटेशन पैकेज द्वारा प्रदान की गई एंड्रॉइड में मार्कर एनोटेशन उपलब्ध है
    documentation

  • org.eclipse.jdt.annotation.NonNull
    स्थिर कोड विश्लेषण के लिए ग्रहण द्वारा प्रयुक्त
    documentation


एंड्रॉयड

यह जवाब एंड्रॉइड विशिष्ट है। एंड्रॉइड में समर्थन support-annotations नामक समर्थन पैकेज है। यह dozens http://tools.android.com/tech-docs/support-annotations एनोटेशन प्रदान करता है और NonNull , Nullable इत्यादि जैसे सामान्य भी प्रदान करता है।

समर्थन-एनोटेशन पैकेज जोड़ने के लिए, अपने build.gradle में निम्न निर्भरता जोड़ें:

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

और फिर उपयोग करें:

import android.support.annotation.NonNull;

void foobar(@NonNull Foo bar) {}

अगर कोई इंटेलिजे कक्षाओं की तलाश में है: तो आप उन्हें मेवेन रिपोजिटरी से प्राप्त कर सकते हैं

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

एंड्रॉइड प्रोजेक्ट्स के लिए आपको android.support.annotation.NonNull और android.support.annotation.Nullable उपयोग करना चाहिए। ये और अन्य उपयोगी एंड्रॉइड-विशिष्ट एनोटेशन समर्थन लाइब्रेरी में उपलब्ध हैं।

http://tools.android.com/tech-docs/support-annotations :

समर्थन लाइब्रेरी को इन एनोटेशन के साथ भी एनोटेट किया गया है, इसलिए समर्थन लाइब्रेरी के उपयोगकर्ता के रूप में, एंड्रॉइड स्टूडियो पहले ही आपके कोड की जांच करेगा और इन एनोटेशन के आधार पर संभावित समस्याओं को ध्वजांकित करेगा।


क्या सूर्य का अपना समय नहीं है? यह क्या है:
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-com.sun/istack/com.sun.istack.internal.htm

ऐसा लगता है कि जावा के उन सभी संस्करणों के साथ पैक किया गया है जो मैंने पिछले कुछ वर्षों में उपयोग किया है।

संपादित करें: जैसा कि नीचे दी गई टिप्पणियों में बताया गया है, आप शायद इनका उपयोग नहीं करना चाहते हैं। उस स्थिति में, मेरा वोट इंटेलिजे जेटब्रेन एनोटेशन के लिए है!


चूंकि ओरेकल ने इस समय के लिए @NonNull (और @Nullable) को मानकीकृत नहीं करने का निर्णय लिया है, मुझे डर है कि कोई अच्छा जवाब नहीं है। हम सब कुछ कर सकते हैं एक व्यावहारिक समाधान खोजने के लिए और मेरा निम्नानुसार है:

वाक्य - विन्यास

पूरी तरह से स्टाइलिस्ट दृष्टिकोण से मैं जावा को छोड़कर आईडीई, फ्रेमवर्क या किसी टूलकिट के किसी भी संदर्भ से बचना चाहता हूं।

यह नियम बताता है:

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

जो हमें या तो javax.validation.constraints या javax.annotation के साथ छोड़ देता है। पूर्व जेईई के साथ आता है। यदि यह javax.annotation से बेहतर है, जो अंततः जेएसई के साथ आ सकता है या कभी भी नहीं, बहस का विषय है। मैं व्यक्तिगत रूप से javax.annotation पसंद करता हूं क्योंकि मुझे जेईई निर्भरता पसंद नहीं है।

यह हमें छोड़ देता है

javax.annotation

जो सबसे छोटा भी है।

केवल एक वाक्यविन्यास है जो बेहतर होगा: java.annotation.Nullable। चूंकि अन्य पैकेज अतीत में जावैक्स से जावा तक स्नातक की उपाधि प्राप्त करते हैं, इसलिए javax.annotation सही दिशा में एक कदम होगा।

कार्यान्वयन

मैं उम्मीद कर रहा था कि वे सभी मूल रूप से एक ही मामूली कार्यान्वयन है, लेकिन एक विस्तृत विश्लेषण से पता चला कि यह सच नहीं है।

समानता के लिए सबसे पहले:

@NonNull एनोटेशन में सभी की रेखा है

public @interface NonNull {}

के अलावा

  • org.jetbrains.annotations जो इसे @NotNull कहते हैं और इसका एक छोटा कार्यान्वयन है
  • javax.annotation जो अब एक कार्यान्वयन है
  • javax.validation.constraints जो इसे @NotNull भी कहते हैं और एक कार्यान्वयन है

@Nullable एनोटेशन सभी लाइन है

public @interface Nullable {}

अपने छोटे कार्यान्वयन के साथ org.jetbrains.annotations (दोबारा) को छोड़कर।

मतभेदों के लिए:

एक हड़ताली वह है

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

सभी में रनटाइम एनोटेशन (@Retention (RUNTIME) है, जबकि

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

केवल संकलन समय (@Retention (वर्ग)) हैं।

जैसा कि इस एसओ उत्तर में वर्णित है, रनटाइम एनोटेशन का प्रभाव किसी से भी कम सोच सकता है, लेकिन संकलन समय के अलावा रनटाइम चेक करने के लिए उन्हें उपकरण सक्षम करने का लाभ होता है।

एक और महत्वपूर्ण अंतर यह है कि कोड में एनोटेशन का उपयोग किया जा सकता है। दो अलग-अलग दृष्टिकोण हैं। कुछ पैकेज जेएलएस 9.6.4.1 स्टाइल संदर्भों का उपयोग करते हैं। निम्नलिखित तालिका एक सिंहावलोकन देता है:

                                FIELD   METHOD  PARAMETER LOCAL_VARIABLE 
android.support.annotation      X       X       X   
edu.umd.cs.findbugs.annotations X       X       X         X
org.jetbrains.annotation        X       X       X         X
lombok                          X       X       X         X
javax.validation.constraints    X       X       X   

org.eclipse.jdt.annotation, javax.annotation और org.checkerframework.checker.nullness.qual जेएलएस 4.11 में परिभाषित संदर्भों का उपयोग करें, जो मेरी राय में ऐसा करने का सही तरीका है।

यह हमें छोड़ देता है

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

इस दौर में

कोड

आगे के विवरणों की तुलना करने में आपकी सहायता के लिए मैं नीचे प्रत्येक एनोटेशन के कोड को सूचीबद्ध करता हूं। तुलनात्मक बनाने के लिए मैंने टिप्पणियां, आयात और @ दस्तावेज एनोटेशन हटा दिया। (वे सभी एंड्रॉइड पैकेज से कक्षाओं को छोड़कर @Documented था)। मैंने लाइनों और @ टाउन फ़ील्ड को फिर से व्यवस्थित किया और योग्यता को सामान्यीकृत किया।

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 {}

पूर्णता के लिए, यहां @ निरर्थक कार्यान्वयन हैं:

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 {}

निम्नलिखित दो पैकेजों में @ Nullable नहीं है, इसलिए मैं उन्हें अलग-अलग सूचीबद्ध करता हूं, लोम्बोक में एक सुंदर उबाऊ @ नॉननुल है। 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();
    }
}

समर्थन

मेरा अनुभव बनाएं javax.annotation कम से कम ग्रहण और बॉक्सर से परीक्षक फ्रेमवर्क द्वारा समर्थित है।

सारांश

मेरा आदर्श एनोटेशन चेकर फ्रेमवर्क कार्यान्वयन के साथ जावा.नोटेशन सिंटैक्स होगा।

यदि आप चेकर फ्रेमवर्क का उपयोग नहीं करना चाहते हैं तो javax.annotation (JSR-305) अभी भी समय के लिए आपकी सबसे अच्छी शर्त है।

यदि आप चेकर फ्रेमवर्क में खरीदना चाहते हैं तो बस अपने org.checkerframework.checker.nullness.qual का उपयोग करें।

सूत्रों का कहना है

  • एंड्रॉइड -support.1support1annotation एंड्रॉइड-5.1.1_r1.jar से
  • edu.umd.cs.findbugs.annotations findbugs-annotations-1.0.0.jar से
  • org.eclipse.jdt.annotation org.eclipse.jdt.annotation_2.1.0.v20160418-1457.jar से org.eclipse.jdt.annotation
  • org.jetbrains.annotations jetbrains-annotations-13.0.jar से
  • gwt-dev-2.5.1-sources.jar से javax.annotation
  • checkg-framework-2.1.9.zip से org.checkerframework.checker.nullness.qual
  • lombok से lombok प्रतिबद्ध f6da35e4c4f3305ecd1b415e2ab1b9ef8a9120b4
  • javax.validation.constraints सत्यापन-एपीआई-1.0.0.GA-sources.jar से

जावा 8 में ऐसा करने का एक और तरीका है। मुझे जो कुछ चाहिए वह पूरा करने के लिए मैं 2 चीजें कर रहा हूं:

  1. Java.util.Optional के साथ nullable फ़ील्ड लपेटकर प्रकार के साथ स्पष्ट नलिका फ़ील्ड बनाना
  2. यह जांच कर रहा है कि सभी गैर नामुमकिन फ़ील्ड java.util.Objects.requireNonNull साथ निर्माण समय पर शून्य नहीं हैं

उदाहरण:

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);
  }

तो मेरा सवाल यह है कि, जावा 8 का उपयोग करते समय हमें एनोटेट करने की भी आवश्यकता है?

संपादित करें: मुझे बाद में पता चला कि कुछ तर्कों में Optional का उपयोग करने के लिए एक बुरी आदत मानते हैं, यहां पेशेवरों और विपक्ष के साथ अच्छी चर्चा है, तर्कों में जावा 8 का वैकल्पिक क्यों उपयोग नहीं किया जाना चाहिए


दुर्भाग्यवश, JSR 308 इस प्रोजेक्ट की तुलना में अधिक मूल्य नहीं जोड़ देगा स्थानीय नल सुझाव यहां

Java 8 एक डिफ़ॉल्ट एनोटेशन या अपने स्वयं के Checker फ्रेमवर्क के साथ नहीं आएगा। फाइंड-बग या JSR 305 , यह जेएसआर ज्यादातर अकादमिक टीमों के एक छोटे समूह द्वारा खराब रखरखाव किया जाता है।

इसके पीछे कोई वाणिज्यिक शक्ति नहीं है, इस प्रकार JSR 308 ने EDR 3 ( JCP अर्ली ड्राफ्ट रिव्यू) लॉन्च किया है, जबकि Java 8 को 6 महीने से भी कम समय में शिप करना है: -ओ 310 बीटीडब्ल्यू के समान। लेकिन 308 Oracle विपरीत अब इसके संस्थापकों से जावा चार्जर को नुकसान पहुंचाने के लिए कम से कम चार्ज किया गया है।

Checker Framework और JSR 308 पीछे की तरह प्रत्येक प्रोजेक्ट, विक्रेता और अकादमिक वर्ग अपनी खुद की मालिकाना चेकर एनोटेशन बनायेगा।

आने वाले सालों के लिए सोर्स कोड असंगत बनाना, जब तक कि कुछ लोकप्रिय समझौता नहीं मिल पाए और शायद Java 9 या 10 जोड़ा गया हो या Apache Commons या Google Guava जैसे फ्रेमवर्क के माध्यम से ;-)


बस यह इंगित करते हुए कि जावा सत्यापन API ( javax.validation.constraints.* ) एक @Nullable एनोटेशन के साथ नहीं आता है, जो स्थिर विश्लेषण संदर्भ में बहुत मूल्यवान है। यह रनटाइम बीन सत्यापन के लिए समझ में आता है क्योंकि यह जावा में किसी भी गैर-आदिम क्षेत्र के लिए डिफ़ॉल्ट है (यानी मान्य / लागू करने के लिए कुछ भी नहीं)। उद्देश्यों के लिए कहा गया है कि विकल्पों के प्रति वजन करना चाहिए।


मैं IntelliJ एक का उपयोग करता हूं, क्योंकि मैं ज्यादातर इंटेलिजे फ्लैगिंग चीजों से चिंतित हूं जो एनपीई उत्पन्न कर सकते हैं। मैं मानता हूं कि जेडीके में मानक एनोटेशन नहीं होने से निराशा होती है। इसे जोड़ने की बात है, यह इसे जावा 7 में बना सकती है। इस मामले में से चुनने के लिए एक और होगा!


यदि आप एंड्रॉइड के लिए विकास कर रहे हैं, तो आप कुछ हद तक ग्रहण से जुड़े हुए हैं (संपादित करें: लेखन के समय, अब और नहीं), जिसकी अपनी टिप्पणियां हैं। यह ग्रहण 3.8+ (जूनो) में शामिल है, लेकिन डिफ़ॉल्ट रूप से अक्षम है।

आप इसे प्राथमिकता> जावा> कंपाइलर> त्रुटियों / चेतावनियों> शून्य विश्लेषण (नीचे पर संकुचित अनुभाग) पर सक्षम कर सकते हैं।

"एनोटेशन-आधारित शून्य विश्लेषण सक्षम करें" की जांच करें

http://wiki.eclipse.org/JDT_Core/Null_Analysis#Usage में सेटिंग्स पर अनुशंसाएं हैं। हालांकि, अगर आपके पास अपने कार्यक्षेत्र (जैसे फेसबुक एसडीके) में बाहरी परियोजनाएं हैं, तो वे उन सिफारिशों को पूरा नहीं कर सकते हैं, और आप शायद उन्हें प्रत्येक एसडीके अपडेट के साथ ठीक नहीं करना चाहते हैं ;-)

मैं उपयोग करता हूं:

  1. शून्य सूचक पहुंच: त्रुटि
  2. शून्य विनिर्देश का उल्लंघन: त्रुटि (बिंदु # 1 से जुड़ा हुआ)
  3. संभावित शून्य सूचक पहुंच: चेतावनी (अन्यथा फेसबुक एसडीके चेतावनी होगी)
  4. शून्य एनोटेशन और शून्य अनुमान के बीच संघर्ष: चेतावनी (बिंदु # 3 से जुड़ा हुआ)

जावा 7 फीचर्स सूची के मुताबिक जेएसआर -308 टाइप एनोटेशन जावा 8 में स्थगित कर दिए गए हैं। जेएसआर -305 एनोटेशन का भी उल्लेख नहीं किया गया है।

नवीनतम जेएसआर -308 ड्राफ्ट के appendix में जेएसआर -305 की स्थिति पर थोड़ी सी जानकारी है। इसमें अवलोकन शामिल है कि जेएसआर -305 एनोटेशन को छोड़ दिया जाना प्रतीत होता है। जेएसआर -305 पेज इसे "निष्क्रिय" के रूप में भी दिखाता है।

इस बीच, व्यावहारिक उत्तर एनोटेशन प्रकारों का उपयोग करना है जो सबसे व्यापक रूप से उपयोग किए जाने वाले औजारों द्वारा समर्थित हैं ... और यदि स्थिति बदलती है तो उन्हें बदलने के लिए तैयार रहें।

वास्तव में, जेएसआर -308 किसी भी एनोटेशन प्रकार / कक्षाओं को परिभाषित नहीं करता है, और ऐसा लगता है कि उन्हें लगता है कि यह दायरे से बाहर है। (और वे सही हैं, जेएसआर -305 के अस्तित्व को देखते हुए)।

हालांकि, अगर जेएसआर -308 वास्तव में इसे जावा 8 में बनाने जैसा दिखता है, तो मुझे आश्चर्य नहीं होगा अगर जेएसआर -305 में रुचि बनी हुई है। AFAIK, जेएसआर -305 टीम ने औपचारिक रूप से अपने काम को त्याग दिया नहीं है। वे सिर्फ 2+ सालों से चुप रहे हैं।

यह दिलचस्प है कि बिल पुग (जेएसआर -305 के लिए तकनीकी नेतृत्व) FindBugs के पीछे लड़के में से एक है।


Another option is the annotations provided with ANTLR 4. Following Pull Request #434 , the artifact containing the @NotNull and @Nullable annotations includes an annotation processor that produces compile-time errors and/or warnings in the event one of these attributes is misused (for example, if both are applied to the same item, or if @Nullable is applied to item with a primitive type). The annotation processor provides additional assurance during the software development process that the information conveyed by the application of these annotations is accurate, including in cases of method inheritance.


If you are building your application using Spring Framework I would suggest using javax.validation.constraints.NotNull comming from Beans Validation packaged in following dependency:

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

The main advantage of this annotation is that Spring provides support for both method parameters and class fields annotated with javax.validation.constraints.NotNull . All you need to do to enable support is:

  1. supply the api jar for beans validation and jar with implementation of validator of jsr-303/jsr-349 annotations (which comes with Hibernate Validator 5.x dependency):

    <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. provide MethodValidationPostProcessor to spring's context

      @Configuration
      @ValidationConfig
      public class ValidationConfig implements MyService {
    
            @Bean
            public MethodValidationPostProcessor providePostProcessor() {
                  return new MethodValidationPostProcessor()
            }
      }
    
  3. finally you annotate your classes with Spring's org.springframework.validation.annotation.Validated and validation will be automatically handled by Spring.

उदाहरण:

@Service
@Validated
public class MyServiceImpl implements MyService {

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

When you try calling method doSomething and pass null as the parameter value, spring (by means of HibernateValidator) will throw ConstraintViolationException . No need for manuall work here.

You can also validate return values.

Another important benefit of javax.validation.constraints.NotNull comming for Beans Validation Framework is that at the moment it is still developed and new features are planned for new version 2.0.

What about @Nullable ? There is nothing like that in Beans Validation 1.1. Well, I could arguee that if you decide to use @NotNull than everything which is NOT annotated with @NonNull is effectively "nullable", so the @Nullable annotation is useless.





ide