[Hawkular-dev] @Null / @NotNull

[Thomas Segismont]

To clarify, the conversation started talking about validation of a 
required constructor parameter. So Optional does not apply here.

Also, on how to use Optional in general, this is interesting:
http://blog.joda.org/2014/11/optional-in-java-se-8.html
|
-> "My only fear is that Optional will be overused. Please focus on 
using it as a return type (from methods that perform some useful piece 
of functionality)."

As for using annotations for null/notnull, the IDE I use infers it most 
of the time, so I personally don't feel the need of using it.

Le 02/03/2015 14:42, Michael Burman a écrit :
> Hi,
>
> This is actually very good read about Optional benefits (with lambdas especially): http://vanillajava.blogspot.fi/2015/01/java-8-optional-is-not-just-for.html
>
> Then again, I hope we don't start to use Optional when something really isn't optional. That kills readability.
>
>    -  Micke
>
> ----- Original Message -----
> From: "John Sanda" <jsanda at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, 2 March, 2015 2:54:28 PM
> Subject: Re: [Hawkular-dev] @Null / @NotNull
>
> 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.
>
> [1] http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html
>
>
>
>
> On Mar 2, 2015, at 5:27 AM, Heiko W.Rupp < hrupp at redhat.com > 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-should-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
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>