Short Answer: No, but Yes in the long term... Long Answer: Originally, (as of February 1.) Jochen proposed to introduce them into commons-lang, with mixed results for the answers. So i think they've not yet have made it into master, or do they?
I rummaged through central, and of the modules to be found there beneath org/apache/commons there are just two, that actually reference the com.google.code.finbugs:jsr305:jar, and both are maven plugins: The commons-release-plugin and the commons-weaver-maven-plugin (not yet checked, whether they do transitively so). So I guess, this isn't a pressing issue for commons in general or lang specifically. I also take it, that commons always has been cautions not to light heartedly introduce dependencies, and foreign dependencies at that, into its core modules lang, collections, math etc. If commons made it this far without jsr305, don't start introducing this doomed package now. Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr Von: "Gary Gregory" <garydgreg...@gmail.com> An: "Commons Developers List" <dev@commons.apache.org> Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable So... it is my impression now that we should remove these annotations. Is that right? Gary On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <t...@online.de> wrote: > Not exactly, although that also seems, what the author of > https://jspecify.dev/_sources/index.rst.txt is thinking. > But given, that the last attempt at this went nowhere, and has been > abandoned about 10 years ago, I think it is rather unlikely, that this one > would make the difference. > > And why should it be necessary for the user, to know the details of the > interpretation of the checking framework? > Annotations are kind of interfaces, and as such may be interpreted just as > any other interface as defining element of a contract, which could be > detailed in Javadoc. The same way as Eclipse Link and Hibernate do with JPA > annotations, while at least hibernate still also works with its own > annotations. > > In fact, @NotNull and its compannions can all be interpreted as describing > a predicate applying to certain elements of the source tree. So all what is > needed, is to match the annotations with the predicates, the framework can > support. The challenge is in the inference, when these predicates are > applied to the source tree. > > This way, a checker framework may take also advantage of the knowledge > hidden in foreign annotations: JPA, Hibernate, Jackson all have constructs > for indicating nullability and attribute sizes, that might be of use. > > > > > > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr > Von: "Gary Gregory" <garydgreg...@gmail.com> > An: "Commons Developers List" <dev@commons.apache.org> > Betreff: Re: [lang] Introduce @NonNull, and @Nullable > Isn't the root issue is that all toolchains need to agree on the new > annotations? What's that going to be? > > On Sun, Feb 7, 2021, 17:56 si...@ochsenreither.de <si...@ochsenreither.de> > wrote: > > > > > Agree on that – adding a dependency on the JSR-305 jar is a really really > > bad idea for all the reasons already outlined. I'll add another one: > > > > At my place, we have actively been removing any usage of these > annotations > > as you simply can't use these annotations and the "real" > javax.annotations > > package (javax.annotation:javax.annotation-api) under the module system > > (that was introduced in Java 9, for the record). > > > > People are already working on a replacement library (Jetbrains, Google, > > others), but I forgot the exact URL due to a lack of interest. > > (The JSR-305 approach to nullability is wrong, broken, and will never > work > > reliably from my POV.) > > > > Cheers, > > > > Simon > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
