I find them to be useful in two ways. 1) The document which parameters and return values may be null, and which can't.
2) I use them in conjunction with IntelliJ's Constant Conditions and Exceptions inspection. (This inspection lets me specify what annotations to use for Nullable and NotNull, so I'm not restricted to IntelliJ's annotations. When I use it this way, I usually default to @NotNull, so I only need to specify @Nullable. Also, I use them in combination with their @Contract annotation. When I do this, I get a lot of blowback from other developers, because it smells like Design-By-Contract. It's actually a (small) subset of Design by Contract. I've used Design by Contract, and it's a pain in the buns. But I've also used IntelliJ's subset of DOC, and it's very easy. Contract is mainly useful when you want to specify under what conditions a method will throw an Exception. So if a null input parameter always throws an Exception, you can specify this in a Contract, which helps IntelliJ track nullability problems. I'm not sure we should use it in Apache's code. — Miguel Muñoz On Wed, Aug 26, 2020 at 6:48 AM Matt Sicker <boa...@gmail.com> wrote: > FindBugs and SpotBugs support the annotations. I mentioned that instead of > the javax package version of the annotations for the JPMS reason mentioned > by someone else earlier. That’s what we’re using in Jenkins (along with a > mix of which annotation sets are used, but that’s the nature of a plugin > ecosystem), and it works for downstream users, too. > > On Wed, Aug 26, 2020 at 08:40 Gary Gregory <garydgreg...@gmail.com> wrote: > > > Does SpotBugs use these annotations? If not, can SB make use of any > > > > annotations? > > > > > > > > Gary > > > > > > > > On Wed, Aug 26, 2020 at 2:30 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > > > wrote: > > > > > > > > > For what it is worth: > > > > > > > > > > 1. Generally speaking - and IMHO - these annotations only make sense > in a > > > > > particular tooling setup(s) - like considering values which can be null > > by > > > > > code analysis and not by spec (@NotNull) - which I'm not sure we have > so > > it > > > > > is mainly about making it consumer friendly but how do we guarantee our > > > > > meta are right and don't create false positives? Until we can guarantee > > it, > > > > > it sounds like we can only bring drawbacks by adding it and users can > > > > > trivially solve it since if he already uses @NotNull he puts it in his > > code > > > > > at a higher level anyway. > > > > > 2. Please don't use javax.annotation.* since, thanks JPMS, it can make > > the > > > > > code not compilable on java >= 9 - a package must be owned by a single > > > > > module. (Not)Nullable static check is generally about the annotation > > > > > simple name and not the package so you can just duplicate the 1-2 > > > > > annotations you want in [lang], it is a saner compromise in today's > > > > > ecosystem. > > > > > > > > > > Romain Manni-Bucau > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > > > <http://rmannibucau.wordpress.com> | Github < > > > > > https://github.com/rmannibucau> | > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > > < > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > > > > > > > > > Le mer. 26 août 2020 à 01:30, Matt Sicker <boa...@gmail.com> a écrit : > > > > > > > > > > > Runtime retention still doesn’t require the annotations to be present > > on > > > > > > the classpath unless you perform reflection on them (I forget the > > > > > > specifics). It’s a feature specific to annotations. > > > > > > > > > > > > On Tue, Aug 25, 2020 at 14:36 Jochen Wiedmann < > > jochen.wiedm...@gmail.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Tue, Aug 25, 2020 at 9:08 PM sebb <seb...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > AFAIK that means Maven won't download the dependency. > > > > > > > > > > > > > > > Surely that makes it harder for the developer? > > > > > > > > > > > > > > > > > > > > > > > > > > > > No, it means that Maven won't add the dependency to a distribution. > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, I've got a question: These annotations have > > > > > > > > > > > > > > @Retention(Runtime). (See > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://www.javadoc.io/doc/com.google.code.findbugs/jsr305/latest/javax/annotation/Nullable.html > > > > > > > .) > > > > > > > > > > > > > > Aren't we enforcing the presence of the respective jar at runtime? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jochen > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > Look, that's why there's rules, understand? So that you think > before > > > > > > > > > > > > > > you break 'em. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Matt Sicker <boa...@gmail.com> > > > > > > > > > > > > > > > -- > Matt Sicker <boa...@gmail.com> >
