Hi. On Thu, Sep 13, 2012 at 01:34:38PM -0400, Kish, Robert wrote: > Hello - > I've been following this mailing list for a few months, and I > feel this is a good opportunity to provide a first opinion on a topic. > > I find option 2, to never check for null, the best option. But, I think > it would work even better with annotations such as package level > @NonNullByDefault, which is what CM appears to follow. For functions > that allow null, they could be tagged @Nullable. > > These annotations have been made more popular by Eclipse Juno including > easier support for them, and I find in my own code, they are nice to > use. When using these annotations, any superfluous null checks inside > the CM library would trigger a compiler warning that they're not needed. > > Any CM functions being called externally would be flagged that they > don't allow null values to be passed in. > > In theory, we'd have compile time null checking, so no NPE at all. > > Note that I'm not suggesting that these annotations be used now, but if > they were to be used one day, there would be little changes needed to CM > code (no compiler warnings to remove due to unnecessary null checks).
Thanks for this input. I'd also think that using annotations is the next step for increased consistency (i.e. a concise syntax that spares the developers from repetitive bits of code and allowing automatic enforcement of various constraints). Unfortunately, that's not for CM at this time since it's still supposed to be source-compatible with Java 5 and cannot depend from external libraries. I'm not sure, but I think that we also cannot use the extensions of JavaEE (?). A temporary solution would be that we locally implement the annotation code (?). Maybe we can copy/paste it from somewhere (?). Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
