[Hawkular-dev] @Null / @NotNull

[Lukas Krejci]

I'm late to the game but I am very MUCH in favor of introducing these into the 
codebase.

For me the annotations bring in the clear intention of the writer that is 
otherwise potentially complex to deduce from the code itself.

IDEs can try to infer the intention of the writer only to an extent and give 
up with methods of certain complexity.

Also, if one annotates methods as returning @Nonnull, the IDE (Idea in my 
case) can be sure of it and will flag any possibility of a null return for me. 
If the annotation is NOT there, all the IDE can assume is that the method 
returns a nullable value.

@Nonnull on parameters is even more useful, because the IDE will flag any 
potentially unsafe method invocation with a possibly null value. If the 
annotation is NOT present, all the IDE can infer is to offer a nullity check 
on method params in the method body - which is exactly not what the writer 
wanted to do ;)

Again, this seems useless in trivial examples, but I've benefited from using 
these annotations many times in any non-trivial code.

On Monday, March 02, 2015 11:27:31 Heiko W.Rupp wrote:
> Hey,
> 
> as we were having a discussion this morning on #hawkular-dev about null
> 
> I think we should start (on top of writing more JavaDoc) using
> annotations to mark methods and method parameters that
> allow being null / not null and if they may return null or not.
> 
> This is especially important on API classes(*1), that may be
> consumed by 3rd parties that may or may not have insight
> into source of the implementation (on top of that, such annotations
> are an enhancement of the API contract).
> 
> I know we have been talking about that in the past without
> no real result. Luckily since then JSR 308 has been
> marked as final and thus a standard exists, that includes such
> annotations (+ a checking framework, + tooling to retroactively add
> such annotations to existing source).
> 
> See http://types.cs.washington.edu/checker-framework/
> and http://mvnrepository.com/artifact/org.checkerframework for mvn artifacts
> 
> http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10
> <- annotations
> http://types.cs.washington.edu/checker-framework/current/api/ <- Javadoc
> 
> Another option are the org.jetbrains versions of the annotations, which are
> around for a while.
> 
> If we only care about documentation, but not compile time and/or static
> analysis, we can also use the ones from BeanValidation, which live under
> the javax package spaces (iirc). *2
> 
> Here is a more complete list of frameworks
> http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-sho
> uld-i-use
> 
> 
> 
> 
> *1) Java and REST
> *2) BV may be a good idea for more complex input like in alert definition
> 
> 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev