This is already in Commons Lang master which is why I want to remove it until there is a long term plan we can agree on.
Gary On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <t...@online.de> wrote: > > 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 > >
