Proposal: Elvis and Other Null-Safe Operators (original) (raw)

cadenza at paradise.net.nz cadenza at paradise.net.nz
Tue Mar 3 13:07:17 PST 2009

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

More information about the coin-dev mailing list