Well, it seems we are about to hijack this thread: Optional is better because of things like better compiler checking, avoiding NPEs, and lower cyclomatic complexity (less defensive programming). Boxed types are just simpler and less verbose. In the specific case of domain objects it seems to me using optional will result in more code. Based on how the tests code was turning out, and seeing as the null values had fairly obvious meaning, it seemed like that trade-off (use optional) was not worth it in this case (neutron v2-style domain classes). Perhaps good counterexamples can be found in actual (not tests) user code? Also note that it would be easy to switch to Optional. It should already be supported by our GSON. ________________________________________ From: Jeremy Daggett [jeremy.dagg...@rackspace.com] Sent: Thursday, August 21, 2014 1:36 PM To: dev@jclouds.apache.org Subject: Re: antlr4 Annotation Processor
Thanks for all the feedback so far! Zack, would you be able to provide more detail on the boxed types/nullables instead of using Optional, and possibly why one approach is better than the other? /jd On 8/15/14, 8:42 AM, "Zack Shoylev" <zack.shoy...@rackspace.com> wrote: >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/
