I think this is mostly about better documenting the annotations or using standard annotations that findbugs understands - less so about more magic.
About Optional vs null - new code I have been working on has been heavily using boxed types/nullables instead of optional.. so we should talk about that too :) ________________________________________ From: Andrew Gaul [g...@apache.org] Sent: Thursday, August 14, 2014 7:59 PM To: dev@jclouds.apache.org Subject: Re: antlr4 Annotation Processor On Tue, Aug 12, 2014 at 10:26:15AM +0100, Aled Sage wrote: > There are way too many options out there [1]. I haven't tried antlr4 > so would also appreciate a summary of why it's better than the other > options. > > Following Andrew Gaul's point, I'm not convinced about adding > @NonNull all over the place. Most of our code is guaranteed to not > return null. > e.g. guava did not choose to use @NonNull on ImmutableList.of() or > on Iterables.find(...)! > > Guava chose to use javax.annotation.Nullable (though JSR-305 is now > inactive). > That has good support in IDEs and tools like FindBugs. I might have misunderstood the proposal; do we want to use some new magic annotation-based programming, e.g., Lombok, or do we merely want a standard replacement for @Nullable and other annotations? For the former, I strongly oppose as before. For the latter, I believe jclouds uses its own annotations instead of com.google.code.findbugs.jsr305 as a concession to Karaf. We moved from jsr305 to org.jclouds.javax.annotation in commit 87dd235. I weakly support using some standard annotation for to enable FindBugs but realistically few people have fixed any warnings in the last several years. For new code we should avoid null and prefer Guava Optional. -- Andrew Gaul http://gaul.org/
