[jdt-core-dev] Nullness Features in Juno

[Marcus Thiesen <marcus@xxxxxxxxxxx>]

Hello List,

I wanted to give some feedback and general ideas about the new
Nullness Features in Juno. I hope this is the correct place to do so,
otherwise please direct me to another place.

I tried them on some projects which used the JSR 305 Annotations as
used by Findbugs 1.x.

- @Override and derived Nullness
Findbugs uses the nullness information when annotated on an interface.
It does or did not confirm that an actual implementation has the same
annotations as the interface. This lead us to disallow any nullness
annotations on methods tagged with @Override. This is unfortunately
the complete opposite of what the JDT does now. Is there a special
reason why the nullness is not "inherited" of the interface? Could
this be another option of the compiler?

- Nullness of build in utility Methods (Collections.emptyList())
Is there any way to specify defaults for third party libraries, e. g.
the JDK Library. At the moment I get warnings when returning a
Collections.emptyList() from a @Nonnull method, but the method always
returns a non null value. As we use a lot of utility classes this
limits the usefulness of the feature.

- Nullchecking with Utility Classes (Collections.isEmpty(),
StringUtils.isBlank() )
This is somehow the other way around. We do lots of nullchecking with
utility methods that are itself nullsafe, but the compiler does not
see that.

- Global ignores (Function.apply())
It there a way to add a global ignore? E.g. Google Guavas
Function.apply is annotated with a Nullable argument, but we mostly
use it in list transforms that give a nonnull guarantee. Is there or
will there be any way to suppress that? Or is there any way that I
could create an interface that derives from Function but has a
@Nonnull guarantee?

- JSR 305 vs. the Juno Annotations
JSR 305 specifies a @Nullable annotation for method parameters and a
@CheckForNull annotation for return values because it is more
idiomatic. If I understand the configuration dialog correctly you only
allow one annotation for both. Could this be extended to multiple
annotations?

Thanks for putting all that hard work in one of my most favorite tools.

Have fun,
  Marcus

-- 
Marcus Thiesen :: www.thiesen.org :: @mthiesen :: 0173 / 28 01 82 4