<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">How about using the Optional class introduced in Java instead of null? Not only does it provide documentation like the annotations do, but Optional also provides a rich API that the annotations do not. If you are not familiar with Optional, this article[1] is a good overview.</div><div class=""><br class=""></div><div class="">[1] <a href="http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html" class="">http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html</a></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 2, 2015, at 5:27 AM, Heiko W.Rupp <<a href="mailto:hrupp@redhat.com" class="">hrupp@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Hey,<br class=""><br class="">as we were having a discussion this morning on #hawkular-dev about null<br class=""><br class="">I think we should start (on top of writing more JavaDoc) using<br class="">annotations to mark methods and method parameters that<br class="">allow being null / not null and if they may return null or not.<br class=""><br class="">This is especially important on API classes(*1), that may be <br class="">consumed by 3rd parties that may or may not have insight<br class="">into source of the implementation (on top of that, such annotations<br class="">are an enhancement of the API contract).<br class=""><br class="">I know we have been talking about that in the past without<br class="">no real result. Luckily since then JSR 308 has been<br class="">marked as final and thus a standard exists, that includes such<br class="">annotations (+ a checking framework, + tooling to retroactively add<br class="">such annotations to existing source).<br class=""><br class="">See <a href="http://types.cs.washington.edu/checker-framework/" class="">http://types.cs.washington.edu/checker-framework/</a><br class="">and <a href="http://mvnrepository.com/artifact/org.checkerframework" class="">http://mvnrepository.com/artifact/org.checkerframework</a> for mvn artifacts<br class=""><br class=""><a href="http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10" class="">http://mvnrepository.com/artifact/org.checkerframework/checker-qual/1.8.10</a> <- annotations<br class=""><a href="http://types.cs.washington.edu/checker-framework/current/api/" class="">http://types.cs.washington.edu/checker-framework/current/api/</a> <- Javadoc<br class=""><br class="">Another option are the org.jetbrains versions of the annotations, which are around for a while.<br class=""><br class="">If we only care about documentation, but not compile time and/or static analysis, we can also<br class="">use the ones from BeanValidation, which live under the javax package spaces (iirc). *2<br class=""><br class="">Here is a more complete list of frameworks<br class=""><a href="http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use" class="">http://stackoverflow.com/questions/4963300/which-notnull-java-annotation-should-i-use</a><br class=""><br class=""><br class=""><br class=""><br class="">*1) Java and REST<br class="">*2) BV may be a good idea for more complex input like in alert definition<br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">hawkular-dev mailing list<br class="">hawkular-dev@lists.jboss.org<br class="">https://lists.jboss.org/mailman/listinfo/hawkular-dev<br class=""></div></blockquote></div><br class=""></body></html>