Proposal: Elvis and Other Null-Safe Operators

[cadenza at paradise.net.nz]

> This will be very confusing when you use Foo from another part of your 
> application and expect the value to be non-null and get a NPE. In fact 
> the @Nonnull is positvely misleading.
> 
> Basically, you can't rely on JSR-305. The information needs to be 
> rechecked. Thus, whats the point in using it at all?!! Documentation 
> perhaps? Annotations are not suitable for handling language level issues
> 
> like nulls.

An annotation processor visible to javac could perform the @nonNull check and
cause the compilation to fail.

JSR-305 defines a standard set of annotations with precise defined meaning so
that tools don't need to define their own, and so you don't need to change your
code when you change the tooling. That has great value. With the annotations
standardised the tooling will follow, no doubt some will be implemented as
though they are part of javac, and some will not.

Bruce

Quoting Stephen Colebourne <scolebourne at joda.org>:

> Jeremy Manson wrote:
> >> The principle perceived disadvantage, however, is that it
> encourages,
> >> rather than discourages, the use of null values in APIs.
> > 
> > I would think that the principle disadvantage would be not that it
> > encourages use of null values (which, as you point out, is fine in
> > some contexts), but that it encourages programmers not to think about
> > what happens when there is a null value.
> 
> But that is exactly what already happens today. Most developers are very
> 
> poor at thinking through the null consequences of a method - the happy 
> day scenario is the one focussed on.
> 
> > I can easily imagine
> > programmers using this all of the time without thinking about it, and
> > then being surprised when a null ends up in the wrong place and not
> > knowing how it got there. Even with a simple example:
> > 
> > public String someFunction(String a, String b) {
> > String s = a?.concat("foo");
> > String t = b?.concat(a);
> > return myHashMap?.get(t);
> > }
> > 
> > Now, someFunction returns null. Is it because a was null? Or b was
> > null? Or myHashMap was null? Or there was no mapping for t in
> > myHashMap?
> 
> Or perhaps it doesn't matter, and thats why the code was written that 
> way. Null as 'don't know' or 'don't care' is incredibly common.
> 
> > If you want to cut down on
> > extraneous if-testing, I would use JSR-305's Nullity annotations
> > instead.
> 
> What does this code do when passed null?
> 
> Foo f = new Foo(null);
> int v = f.value;
> 
> public class Foo {
>  public final Integer value;
>  public Foo(@Nonnull Integer value) {
>  this.value = value;
>  }
> }
> 
> There is a NPE at f.value, not at new Foo(null).
> 
> You would think that you could never construct an instance of Foo with a
> 
> val of null, but you can. The @Nonnull annotation doesn't have any real
> 
> meaning unless it is checked using a tool, and javac isn't such a tool.
> 
> This will be very confusing when you use Foo from another part of your 
> application and expect the value to be non-null and get a NPE. In fact 
> the @Nonnull is positvely misleading.
> 
> Basically, you can't rely on JSR-305. The information needs to be 
> rechecked. Thus, whats the point in using it at all?!! Documentation 
> perhaps? Annotations are not suitable for handling language level issues
> 
> like nulls.
> 
> Stephen
> 
>