IMO, I think they are very useful, especially since the IDE (e.g. IntelliJ IDEA) can use them to detect problems (e.g. NPEs) earlier rather than later.
For example, *Spring* 5 just introduced 2 new annotations: @Nullable [1] (declaring possible null parameters, returns values or fields) and @NonNullApi [2] to declare the opposite, non-null parameters and return values. These are very similar in purpose to IntellIJ IDEA's own Null Inspection annotations [3]. It is a simple matter in IJ to configure additional annotations for the IDE to detect *null-safe* and *non-null/required* cases in code. Preferences > Inspections > Java > Probable Bugs > Constant conditions & exceptions > Configure annotations [image: Inline image 1] I am sure Eclipse has similar facilities. It seems many libraries and their APIs are following similar approaches (Google, Findbugs, Vaadin, etc). Also see... https://jcp.org/en/jsr/detail?id=305 And... https://github.com/amaembo/jsr-305/tree/master/ri/src/main/java/javax/annotation For instance... https://github.com/amaembo/jsr-305/blob/master/ri/src/main/java/javax/annotation/Nonnull.java https://github.com/amaembo/jsr-305/blob/master/ri/src/main/java/javax/annotation/Nullable.java Anyway, seems there are several options/approaches you can take. -j [1] http://docs.spring.io/spring/docs/5.0.0.BUILD-SNAPSHOT/javadoc-api/org/springframework/lang/Nullable.html [2] http://docs.spring.io/spring/docs/5.0.0.BUILD-SNAPSHOT/javadoc-api/org/springframework/lang/NonNullApi.html [3] https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html On Fri, Jul 14, 2017 at 9:47 AM, Galen O'Sullivan <gosulli...@pivotal.io> wrote: > What's the general opinion of @NotNull annotations? Would they be useful? > > On Fri, Jul 14, 2017 at 9:23 AM, John Blum <jb...@pivotal.io> wrote: > > > +1 as well. > > > > However, I will caution this... use Java 8's new java.util.Optional class > > in your codebase judiciously. Using it everywhere, especially on > critical > > code paths can and most likely will affect your performance. > > > > Internally, j.u.Optional allocates new objects for nearly every operation > > (e.g. Optional.of(..), Optional.ofNullable(), etc). Be careful of > Optional > > operations that take a *Lambda* since creating a *Lambda* involves > > constructing a new object (exactly like anonymous inner construction). > > > > We just went through this exercise on the *Spring Data* team, introducing > > Java 8 types (e.g.) to our Repository infrastructure and other parts of > the > > SD Commons API and it negatively impacted performance, cutting perf in > half > > (due to Object allocation). As such, we rolled back and took another > > approach to Nullability, primarily by using Annotations and IDE support. > > > > Finally, while it is common to return a Optional<?> from a method call, > it > > is not appropriate to generally accept Optional parameters in your APIs. > > Generally speaking, there is no substitute for validating method > arguments > > than adding assertions (which does not imply just the Java assert > facility > > (that is unreliable since it must explicitly be enabled... $ java ... -ea > > ...), rather, use something like using java.util.Objects or AssertJ).. > > NPEs are not user mistakes, they are library mistakes/bugs. > > > > Food for thought, > > > > -j > > > > > > On Thu, Jul 13, 2017 at 6:13 PM, Jacob Barrett <jbarr...@pivotal.io> > > wrote: > > > > > +1 > > > > > > We are taking a similar approach to refactoring of the C++ client. > > > Specifically with refer to nullptr we are trying to eliminate it from > all > > > public APIs. > > > > > > Sent from my iPhone > > > > > > > On Jul 13, 2017, at 3:17 PM, Kirk Lund <kl...@apache.org> wrote: > > > > > > > > Please try to imagine a world of no nulls. > > > > > > > > https://www.oracle.com/corporate/features/library-in- > > > java-best-practices.html?evite=WWMK170414P00004 > > > > > > > > > > > -- > > -John > > john.blum10101 (skype) > > > -- -John john.blum10101 (skype)
