You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@apache.org> on 2017/07/13 22:17:58 UTC
No nulls
Please try to imagine a world of no nulls.
https://www.oracle.com/corporate/features/library-in-java-best-practices.html?evite=WWMK170414P00004
Re: No nulls
Posted by John Blum <jb...@pivotal.io>.
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 <go...@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 <jb...@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)
Re: No nulls
Posted by Galen O'Sullivan <go...@pivotal.io>.
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 <jb...@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)
>
Re: No nulls
Posted by John Blum <jb...@pivotal.io>.
+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 <jb...@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)
Re: No nulls
Posted by Jacob Barrett <jb...@pivotal.io>.
+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