+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)
