... right into https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem. I thought more about something like a guide to be consulted before introducing a new dependency, instead of a dashboard disclosing the sins post fact :-)
I take that as a no. Thomas Gesendet: Montag, 15. Februar 2021 um 16:59 Uhr Von: "Gary Gregory" <garydgreg...@gmail.com> An: "Commons Developers List" <dev@commons.apache.org> Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable I do not think we need a wiki since each project should have a Maven generated page like https://commons.apache.org/proper/commons-lang/dependencies.html Gary On Mon, Feb 15, 2021 at 9:32 AM Thomas Schapitz <t...@online.de> wrote: > Oh, maybe I should pull more often... > As far as I'm concerned, by all means, remove it, although I'm probably > the least one to call for that. > > And since we are at it: Are you aware of any explicit mentioning of a > dependency policy wrt. commons? > Maybe commons should set up some Wiki page, and start actively managing > that? > A convenient place to point to, when discussions about that occur? > > Thomas > > Gesendet: Montag, 15. Februar 2021 um 14:38 Uhr > Von: "Gary Gregory" <garydgreg...@gmail.com> > An: "Commons Developers List" <dev@commons.apache.org> > Betreff: Re: [lang] Introduce @NonNull, and @Nullable > 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[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 > > > > > > --------------------------------------------------------------------- > 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
