6:40 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev