Re: Re: Re: [lang] Introduce @NonNull, and @Nullable

[Xeno Amess]

glad to hear about this.
this is what I always want...
I wished for this for months...

Gary Gregory  于2021年2月16日周二 上午9:37写道：

> Yes of course, that's fine, but I was only referring to [lang], which is
> the component this thread is about.
>
> Gary
>
> On Mon, Feb 15, 2021, 19:03 sebb  wrote:
>
> > On Mon, 15 Feb 2021 at 18:43, Gary Gregory 
> wrote:
> > >
> > > Can we configure the Maven Enforcer plugin to say "no runtime deps"?
> > > Presumably not that helpful... but still _something_
> >
> > Some components legitimately depend on others at runtime.
> > e.g. VFS on NET.
> >
> > > Gary
> > >
> > >
> > > On Mon, Feb 15, 2021 at 11:48 AM Thomas Schapitz 
> wrote:
> > >
> > > > ... 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" 
> > > > An: "Commons Developers List" 
> > > > 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 
> > 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" 
> > > > > An: "Commons Developers List" 
> > > > > 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 
> 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 packa

Re: Re: Re: [lang] Introduce @NonNull, and @Nullable

[Gary Gregory]

Yes of course, that's fine, but I was only referring to [lang], which is
the component this thread is about.

Gary

On Mon, Feb 15, 2021, 19:03 sebb  wrote:

> On Mon, 15 Feb 2021 at 18:43, Gary Gregory  wrote:
> >
> > Can we configure the Maven Enforcer plugin to say "no runtime deps"?
> > Presumably not that helpful... but still _something_
>
> Some components legitimately depend on others at runtime.
> e.g. VFS on NET.
>
> > Gary
> >
> >
> > On Mon, Feb 15, 2021 at 11:48 AM Thomas Schapitz  wrote:
> >
> > > ... 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" 
> > > An: "Commons Developers List" 
> > > 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 
> 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" 
> > > > An: "Commons Developers List" 
> > > > 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  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" 
> > > > > An: "Commons Developers List" 
> > > > > 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 
> > > wrote:
> >

Re: Re: Re: [lang] Introduce @NonNull, and @Nullable

[sebb]

On Mon, 15 Feb 2021 at 18:43, Gary Gregory  wrote:
>
> Can we configure the Maven Enforcer plugin to say "no runtime deps"?
> Presumably not that helpful... but still _something_

Some components legitimately depend on others at runtime.
e.g. VFS on NET.

> Gary
>
>
> On Mon, Feb 15, 2021 at 11:48 AM Thomas Schapitz  wrote:
>
> > ... 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" 
> > An: "Commons Developers List" 
> > 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  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" 
> > > An: "Commons Developers List" 
> > > 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  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" 
> > > > An: "Commons Developers List" 
> > > > 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 
> > 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
> > > > > interpret

Re: Re: Re: [lang] Introduce @NonNull, and @Nullable

[Gary Gregory]

Can we configure the Maven Enforcer plugin to say "no runtime deps"?
Presumably not that helpful... but still _something_

Gary


On Mon, Feb 15, 2021 at 11:48 AM Thomas Schapitz  wrote:

> ... 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" 
> An: "Commons Developers List" 
> 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  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" 
> > An: "Commons Developers List" 
> > 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  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" 
> > > An: "Commons Developers List" 
> > > 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 
> 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 certai

Aw: Re: Re: [lang] Introduce @NonNull, and @Nullable

[Thomas Schapitz]

... 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" 
An: "Commons Developers List" 
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  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" 
> An: "Commons Developers List" 
> 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  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" 
> > An: "Commons Developers List" 
> > 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  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: &qu

Re: Re: [lang] Introduce @NonNull, and @Nullable

[Gary Gregory]

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  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" 
> An: "Commons Developers List" 
> 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  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" 
> > An: "Commons Developers List" 
> > 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  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" 
> > > An: "Commons Developers List" 
> > > 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:
> > >
> > > >
> > > > Ag

Aw: Re: [lang] Introduce @NonNull, and @Nullable

[Thomas Schapitz]

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" 
An: "Commons Developers List" 
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  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" 
> An: "Commons Developers List" 
> 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  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" 
> > An: "Commons Developers List" 
> > 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-3

Re: [lang] Introduce @NonNull, and @Nullable

[Gary Gregory]

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  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" 
> An: "Commons Developers List" 
> 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  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" 
> > An: "Commons Developers List" 
> > 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
>
>

Re: [lang] Introduce @NonNull, and @Nullable

[Thomas Schapitz]

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" 
An: "Commons Developers List" 
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  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" 
> An: "Commons Developers List" 
> 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 
> 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

Re: Re: [lang] Introduce @NonNull, and @Nullable

[Gary Gregory]

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  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" 
> An: "Commons Developers List" 
> 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 
> 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
>
>

Aw: Re: [lang] Introduce @NonNull, and @Nullable

[Thomas Schapitz]

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" 
An: "Commons Developers List" 
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 
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

Re: [lang] Introduce @NonNull, and @Nullable

[thc202]

I believe Simon was referring to:
https://jspecify.dev/
https://github.com/jspecify/jspecify

The table that shows the participants is not being displayed currently 
(just me?), one can view the source though:

https://jspecify.dev/_sources/index.rst.txt

Worth checking this related thread too:
https://github.com/google/guava/issues/2960

Best regards.

On 07/02/2021 23:37, Gary Gregory wrote:

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 
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

Re: [lang] Introduce @NonNull, and @Nullable

[Gary Gregory]

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 
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
>

Re: [lang] Introduce @NonNull, and @Nullable

[simon]

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

Re: [lang] Introduce @NonNull, and @Nullable

[Thomas]

Hi,

I'd like to point out, that there actually *is* a licensing issue
regarding @NonNull and its siblings in javax.annotations : Not with the
library, but with the prefix 'javax.'. As you might have noted, Oracle
recently closed a deal with the Eclipse Foundation, allowing the Eclipse
Foundation to step into the development of the JEE-API, under one
essential premise: They have to drop the prefix 'javax.' and Eclipse is
going to switch to the prefix 'jakarta.' instead.

Even if 'javax.annotation' & JSR-305 might not be considered part of
deal this makes one thing pretty obvious: Oracle is not going to allow
anybody else to add extend something into any of the 'javax.' packages.
And  since JSR-305 has been without development since 2012, officially
declared 'dormant', it is rather unlikely, this will be taken up again now.

So unless apache-commons is comfortable riding a dead horse, we
shouldn't pull this into any commons module.

This leaves us with 2 options:

- Wait for somebody else to step in. Maybe the good folks at Eclipse
Foundation are interested in taking that up too? They would be certainly
free to duplicate the JSR-305 annotations into the jakarta Namespace.

- Or rolling our own.

I would be in favor of the second option, as this would be easier to
control for commons. Maybe it is finally time to start modules
'annotation' and/or 'annotation-processing' within the commons-sandbox?

Thomas




On 01.02.2021 11:58, Jochen Wiedmann wrote:
> Hi,
>
> as a followup to a discussion, that we had in August 2020, I'd like to
> propose, that we introduce the @NonNull, and @Nullable annotations
> into commons-lang.
>
> Since that discussion, I began to gradually introduce those
> annotations into my own code. From that, I have learned three things:
>
>  1.) Although those annotations have RetentionPolicy.RUNTIME, they are 
> still
>   invisible at runtime. In particular, they do not impose any
> runtime requirements.
>   We *can* use those annotations, but still remain a standalone 
> library.
>  2.) There is no problem with mixed code: You can have some
> classes, that use
>   those annotations, while others don't. Or, to rephrase that:
> Even, if the ultimate
>   target should be, to use those annotations everywhere, they
> can be introduced
>   gradually on a per-class base. We can have the target as a
> long time goal, but
>   start small.
>  3.) Although the annotations aren't present in the compiled code,
> they still provide
>   valuable information, if the source code is present in the
> users IDE, because
>   the user can quickly jump into the respective file. (IDE
> support could be enhanced,
>   for example Eclipse doesn't provide them as quick hints, but
> that's something we
>   can work on.
>   Besides, static code analysis clearly *does* help (at least
> in the current case) to
>   avoid errors. In my opinion, we are the ones, who are
> setting the standards in good
>   code style, and this would clearly be an enhancement in that area).
>
> So, assuming that my proposal should be accepted: How do we proceed? I
> see two alternatives:
>
> a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> "provided" to our dependencies. The scope will guarantee, that users
> aren't affected at all.
> b) We create our own annotations, say
> org.apache.commons.lang3.annotations.NonNull, etc. When using
> Spotbugs, or the respective IDE's, we need to adjust the namespace,
> but that should be doable.
>
> Personally, I'm in favour of using the javax.annotation namespace, thus a).
>
> From my experiences, I conclude that we should also do the following:
>
> - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
> a @NonNull result,
>   because in practice, they are going to be used frequently. (In
> cases, where the compiler
>   doesn't understand, that a value is, in fact, not nullable.)
> - Convince the maintainers of the maven-compiler-plugin, that use of
> those annotations
>   is something, that should be documented in the plugin configuration.
> If that is given,
>   then IDE's might configure themselves automatically without the need
> for IDE specific
>   files.
>
>
> Jochen
>
>
> 1.)
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Matt Sicker]

Provided dependencies typically mean that the dependency is copied
into another dependency (think Java EE APIs typically) and doesn't
need to be added by a runtime dependency. It's kind of the opposite of
the runtime scope which doesn't add it at compile time but does at
runtime.

On Thu, 4 Feb 2021 at 17:46, sebb  wrote:
>
> On Thu, 4 Feb 2021 at 20:28, Jochen Wiedmann  wrote:
> >
> >
> >
> > On 2021/02/02 11:34:09, sebb  wrote:
> >
> > > In which case it should surely be listed as a compile dependency so
> > > that it is picked up automatically?
> >
> > It is also picked up automatically with scope=provided.
>
> Useful to know; the Maven documentation is not explicit on that.
> The name makes it sound as though the user has to provide the jar themselves.
>
> >
> > -
> > 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

RE: [lang] Introduce @NonNull, and @Nullable

[BUnckel]

>> It is also picked up automatically with scope=provided.

>Useful to know; the Maven documentation is not explicit on that.
>The name makes it sound as though the user has to provide the jar themselves.
You're right, the user has to provide the jar themselves. But only if it's 
_needed_ at runtime. Think of the BOM of a application server. You need 
Servlet/JSF/JPA... present at compile time, at runtime it's provided by the app 
server.
Diese Mail wurde aus Datenschutzgründen verschlüsselt versandt.

Re: [lang] Introduce @NonNull, and @Nullable

[sebb]

On Thu, 4 Feb 2021 at 20:28, Jochen Wiedmann  wrote:
>
>
>
> On 2021/02/02 11:34:09, sebb  wrote:
>
> > In which case it should surely be listed as a compile dependency so
> > that it is picked up automatically?
>
> It is also picked up automatically with scope=provided.

Useful to know; the Maven documentation is not explicit on that.
The name makes it sound as though the user has to provide the jar themselves.

>
> -
> 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

Re: [lang] Introduce @NonNull, and @Nullable

[Jochen Wiedmann]

On 2021/02/02 08:10:33, Julian Reschke  wrote: 

> Please see .

I may be missing the point here, so help me: My impression is, that the user 
doesn't need the jsr305 jar in the classpath, if we use it in out sources. If 
so, how should the Java 9 JRE detect the package in another module, unless the 
commons-lang user has added the jar him/herself. (A case, for which I won't 
take responsibility.)

Jochen



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Jochen Wiedmann]

On 2021/02/02 11:34:09, sebb  wrote: 

> In which case it should surely be listed as a compile dependency so
> that it is picked up automatically?

It is also picked up automatically with scope=provided.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Jochen Wiedmann]

On 2021/02/01 16:45:46, Tomo Suzuki  wrote: 
> I like "javax.annotation namespace" too.
> 
> Would you be willing to share more about why the annotation dependency
> should have "provided" scope? If a library (commons-lang) requires a
> dependency at runtime, I believe it should declare it as "compile"
> dependency. In past, I did troubleshooting for
> missing javax.annotation.Nullable
> https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917

Simple reason: Upwards compatibility. So far, using commons-lang was possible 
without any other dependencies.
With scope "compile", we could not guarantee, that this remains the same. As a 
consequence, the next version of commons-lang would not be a drop-in 
replacement for it's predecessor. To update, one would need to add the jsr305 
jar as well.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

AW: [lang] Introduce @NonNull, and @Nullable

[BUnckel]

+1 Downstream projects take transitive dependencies without looking why they 
are needed and if they are needed. One of the root causes for the dependency 
(version) hell.

-Ursprüngliche Nachricht-
Von: Matt Sicker  
Gesendet: Dienstag, 2. Februar 2021 17:35
An: Commons Developers List 
Betreff: Re: [lang] Introduce @NonNull, and @Nullable

> You can use the provided scope to make it compile-time only and avoid 
> requiring it as a runtime dependency.
Diese Mail wurde aus Datenschutzgründen verschlüsselt versandt.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Matt Sicker]

You can use the provided scope to make it compile-time only and avoid
requiring it as a runtime dependency.

On Tue, 2 Feb 2021 at 05:34, sebb  wrote:
>
> On Mon, 1 Feb 2021 at 22:39, Gary Gregory  wrote:
> >
> > Well, it's in a 3rd party jar, just like JUnit and whatever else is needed
> > to complete a decent build...
>
> In which case it should surely be listed as a compile dependency so
> that it is picked up automatically?
>
> Users don't have to do anything to extra to use JUnit for testing.
> They should not have to do anything extra in order to compile.
>
> > On Mon, Feb 1, 2021, 17:22 sebb  wrote:
> >
> > > On Mon, 1 Feb 2021 at 17:56, Matt Sicker  wrote:
> > > >
> > > > Compile time annotations would only be necessary to build the commons
> > > > component.
> > >
> > > i.e. consumers of the source code would be required to provide the
> > > annotations in some form.
> > >
> > > This does not sound ideal.
> > >
> > > > Unless they're runtime scope, but even that can work
> > > > without class loader errors provided you're not reflecting on it.
> > > >
> > > > On Mon, 1 Feb 2021 at 11:45, sebb  wrote:
> > > > >
> > > > > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki 
> > > wrote:
> > > > > >
> > > > > > I like "javax.annotation namespace" too.
> > > > > >
> > > > > > Would you be willing to share more about why the annotation
> > > dependency
> > > > > > should have "provided" scope? If a library (commons-lang) requires a
> > > > > > dependency at runtime, I believe it should declare it as "compile"
> > > > > > dependency.
> > > > >
> > > > > In either case, surely the user will have to provide the relevant
> > > > > annotation jar in order to use the component?
> > > > >
> > > > > > In past, I did troubleshooting for
> > > > > > missing javax.annotation.Nullable
> > > > > > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917
> > > > >
> > > > > That link does not work; it ends up displaying the irrelevant issue:
> > > > >
> > > > >
> > > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-11730?filter=allissues
> > > > >
> > > > > The following link works better:
> > > > > https://issues.apache.org/jira/browse/BEAM-8917
> > > > >
> > > > >
> > > > > > On Mon, Feb 1, 2021 at 5:58 AM Jochen Wiedmann <
> > > jochen.wiedm...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > as a followup to a discussion, that we had in August 2020, I'd
> > > like to
> > > > > > > propose, that we introduce the @NonNull, and @Nullable annotations
> > > > > > > into commons-lang.
> > > > > > >
> > > > > > > Since that discussion, I began to gradually introduce those
> > > > > > > annotations into my own code. From that, I have learned three
> > > things:
> > > > > > >
> > > > > > >  1.) Although those annotations have RetentionPolicy.RUNTIME,
> > > they are
> > > > > > > still
> > > > > > >   invisible at runtime. In particular, they do not impose
> > > any
> > > > > > > runtime requirements.
> > > > > > >   We *can* use those annotations, but still remain a
> > > standalone
> > > > > > > library.
> > > > > > >  2.) There is no problem with mixed code: You can have some
> > > > > > > classes, that use
> > > > > > >   those annotations, while others don't. Or, to rephrase
> > > that:
> > > > > > > Even, if the ultimate
> > > > > > >   target should be, to use those annotations everywhere,
> > > they
> > > > > > > can be introduced
> > > > > > >   gradually on a per-class base. We can have the target as
> > > a
> > > > > > > long time goal, but
> > > > > > >   start small.
> > > > > > >  3.) Although the annotations aren't present in the compiled
> > > code,
> > > > > > > they still provide
> > > > > > >   valuable information, if the source code is present in
> > > the
> > > > > > > users IDE, because
> > > > > > >   the user can quickly jump into the respective file. (IDE
> > > > > > > support could be enhanced,
> > > > > > >   for example Eclipse doesn't provide them as quick hints,
> > > but
> > > > > > > that's something we
> > > > > > >   can work on.
> > > > > > >   Besides, static code analysis clearly *does* help (at
> > > least
> > > > > > > in the current case) to
> > > > > > >   avoid errors. In my opinion, we are the ones, who are
> > > > > > > setting the standards in good
> > > > > > >   code style, and this would clearly be an enhancement in
> > > that
> > > > > > > area).
> > > > > > >
> > > > > > > So, assuming that my proposal should be accepted: How do we
> > > proceed? I
> > > > > > > see two alternatives:
> > > > > > >
> > > > > > > a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> > > > > > > "provided" to our dependencies. The scope will guarantee, that
> > > users
> > > > > > > aren't affected at all.
> > > > > > > b) We create our own annotations, say
> > > > > > > org.apache.commons.lang3.annotations.NonNull, etc. When 

Re: [lang] Introduce @NonNull, and @Nullable

[sebb]

On Mon, 1 Feb 2021 at 22:39, Gary Gregory  wrote:
>
> Well, it's in a 3rd party jar, just like JUnit and whatever else is needed
> to complete a decent build...

In which case it should surely be listed as a compile dependency so
that it is picked up automatically?

Users don't have to do anything to extra to use JUnit for testing.
They should not have to do anything extra in order to compile.

> On Mon, Feb 1, 2021, 17:22 sebb  wrote:
>
> > On Mon, 1 Feb 2021 at 17:56, Matt Sicker  wrote:
> > >
> > > Compile time annotations would only be necessary to build the commons
> > > component.
> >
> > i.e. consumers of the source code would be required to provide the
> > annotations in some form.
> >
> > This does not sound ideal.
> >
> > > Unless they're runtime scope, but even that can work
> > > without class loader errors provided you're not reflecting on it.
> > >
> > > On Mon, 1 Feb 2021 at 11:45, sebb  wrote:
> > > >
> > > > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki 
> > wrote:
> > > > >
> > > > > I like "javax.annotation namespace" too.
> > > > >
> > > > > Would you be willing to share more about why the annotation
> > dependency
> > > > > should have "provided" scope? If a library (commons-lang) requires a
> > > > > dependency at runtime, I believe it should declare it as "compile"
> > > > > dependency.
> > > >
> > > > In either case, surely the user will have to provide the relevant
> > > > annotation jar in order to use the component?
> > > >
> > > > > In past, I did troubleshooting for
> > > > > missing javax.annotation.Nullable
> > > > > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917
> > > >
> > > > That link does not work; it ends up displaying the irrelevant issue:
> > > >
> > > >
> > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-11730?filter=allissues
> > > >
> > > > The following link works better:
> > > > https://issues.apache.org/jira/browse/BEAM-8917
> > > >
> > > >
> > > > > On Mon, Feb 1, 2021 at 5:58 AM Jochen Wiedmann <
> > jochen.wiedm...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > as a followup to a discussion, that we had in August 2020, I'd
> > like to
> > > > > > propose, that we introduce the @NonNull, and @Nullable annotations
> > > > > > into commons-lang.
> > > > > >
> > > > > > Since that discussion, I began to gradually introduce those
> > > > > > annotations into my own code. From that, I have learned three
> > things:
> > > > > >
> > > > > >  1.) Although those annotations have RetentionPolicy.RUNTIME,
> > they are
> > > > > > still
> > > > > >   invisible at runtime. In particular, they do not impose
> > any
> > > > > > runtime requirements.
> > > > > >   We *can* use those annotations, but still remain a
> > standalone
> > > > > > library.
> > > > > >  2.) There is no problem with mixed code: You can have some
> > > > > > classes, that use
> > > > > >   those annotations, while others don't. Or, to rephrase
> > that:
> > > > > > Even, if the ultimate
> > > > > >   target should be, to use those annotations everywhere,
> > they
> > > > > > can be introduced
> > > > > >   gradually on a per-class base. We can have the target as
> > a
> > > > > > long time goal, but
> > > > > >   start small.
> > > > > >  3.) Although the annotations aren't present in the compiled
> > code,
> > > > > > they still provide
> > > > > >   valuable information, if the source code is present in
> > the
> > > > > > users IDE, because
> > > > > >   the user can quickly jump into the respective file. (IDE
> > > > > > support could be enhanced,
> > > > > >   for example Eclipse doesn't provide them as quick hints,
> > but
> > > > > > that's something we
> > > > > >   can work on.
> > > > > >   Besides, static code analysis clearly *does* help (at
> > least
> > > > > > in the current case) to
> > > > > >   avoid errors. In my opinion, we are the ones, who are
> > > > > > setting the standards in good
> > > > > >   code style, and this would clearly be an enhancement in
> > that
> > > > > > area).
> > > > > >
> > > > > > So, assuming that my proposal should be accepted: How do we
> > proceed? I
> > > > > > see two alternatives:
> > > > > >
> > > > > > a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> > > > > > "provided" to our dependencies. The scope will guarantee, that
> > users
> > > > > > aren't affected at all.
> > > > > > b) We create our own annotations, say
> > > > > > org.apache.commons.lang3.annotations.NonNull, etc. When using
> > > > > > Spotbugs, or the respective IDE's, we need to adjust the namespace,
> > > > > > but that should be doable.
> > > > > >
> > > > > > Personally, I'm in favour of using the javax.annotation namespace,
> > thus a).
> > > > > >
> > > > > > From my experiences, I conclude that we should also do the
> > following:
> > > > > >
> > > > > > - Change ObjectUtils.defaultIfNull, and 

Re: [lang] Introduce @NonNull, and @Nullable

[Julian Reschke]

Am 01.02.2021 um 17:45 schrieb Tomo Suzuki:

I like "javax.annotation namespace" too.
...


Please see .

Best regards, Julian

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Gary Gregory]

Well, it's in a 3rd party jar, just like JUnit and whatever else is needed
to complete a decent build...

On Mon, Feb 1, 2021, 17:22 sebb  wrote:

> On Mon, 1 Feb 2021 at 17:56, Matt Sicker  wrote:
> >
> > Compile time annotations would only be necessary to build the commons
> > component.
>
> i.e. consumers of the source code would be required to provide the
> annotations in some form.
>
> This does not sound ideal.
>
> > Unless they're runtime scope, but even that can work
> > without class loader errors provided you're not reflecting on it.
> >
> > On Mon, 1 Feb 2021 at 11:45, sebb  wrote:
> > >
> > > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki 
> wrote:
> > > >
> > > > I like "javax.annotation namespace" too.
> > > >
> > > > Would you be willing to share more about why the annotation
> dependency
> > > > should have "provided" scope? If a library (commons-lang) requires a
> > > > dependency at runtime, I believe it should declare it as "compile"
> > > > dependency.
> > >
> > > In either case, surely the user will have to provide the relevant
> > > annotation jar in order to use the component?
> > >
> > > > In past, I did troubleshooting for
> > > > missing javax.annotation.Nullable
> > > > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917
> > >
> > > That link does not work; it ends up displaying the irrelevant issue:
> > >
> > >
> https://issues.apache.org/jira/projects/BEAM/issues/BEAM-11730?filter=allissues
> > >
> > > The following link works better:
> > > https://issues.apache.org/jira/browse/BEAM-8917
> > >
> > >
> > > > On Mon, Feb 1, 2021 at 5:58 AM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > as a followup to a discussion, that we had in August 2020, I'd
> like to
> > > > > propose, that we introduce the @NonNull, and @Nullable annotations
> > > > > into commons-lang.
> > > > >
> > > > > Since that discussion, I began to gradually introduce those
> > > > > annotations into my own code. From that, I have learned three
> things:
> > > > >
> > > > >  1.) Although those annotations have RetentionPolicy.RUNTIME,
> they are
> > > > > still
> > > > >   invisible at runtime. In particular, they do not impose
> any
> > > > > runtime requirements.
> > > > >   We *can* use those annotations, but still remain a
> standalone
> > > > > library.
> > > > >  2.) There is no problem with mixed code: You can have some
> > > > > classes, that use
> > > > >   those annotations, while others don't. Or, to rephrase
> that:
> > > > > Even, if the ultimate
> > > > >   target should be, to use those annotations everywhere,
> they
> > > > > can be introduced
> > > > >   gradually on a per-class base. We can have the target as
> a
> > > > > long time goal, but
> > > > >   start small.
> > > > >  3.) Although the annotations aren't present in the compiled
> code,
> > > > > they still provide
> > > > >   valuable information, if the source code is present in
> the
> > > > > users IDE, because
> > > > >   the user can quickly jump into the respective file. (IDE
> > > > > support could be enhanced,
> > > > >   for example Eclipse doesn't provide them as quick hints,
> but
> > > > > that's something we
> > > > >   can work on.
> > > > >   Besides, static code analysis clearly *does* help (at
> least
> > > > > in the current case) to
> > > > >   avoid errors. In my opinion, we are the ones, who are
> > > > > setting the standards in good
> > > > >   code style, and this would clearly be an enhancement in
> that
> > > > > area).
> > > > >
> > > > > So, assuming that my proposal should be accepted: How do we
> proceed? I
> > > > > see two alternatives:
> > > > >
> > > > > a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> > > > > "provided" to our dependencies. The scope will guarantee, that
> users
> > > > > aren't affected at all.
> > > > > b) We create our own annotations, say
> > > > > org.apache.commons.lang3.annotations.NonNull, etc. When using
> > > > > Spotbugs, or the respective IDE's, we need to adjust the namespace,
> > > > > but that should be doable.
> > > > >
> > > > > Personally, I'm in favour of using the javax.annotation namespace,
> thus a).
> > > > >
> > > > > From my experiences, I conclude that we should also do the
> following:
> > > > >
> > > > > - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to
> have
> > > > > a @NonNull result,
> > > > >   because in practice, they are going to be used frequently. (In
> > > > > cases, where the compiler
> > > > >   doesn't understand, that a value is, in fact, not nullable.)
> > > > > - Convince the maintainers of the maven-compiler-plugin, that use
> of
> > > > > those annotations
> > > > >   is something, that should be documented in the plugin
> configuration.
> > > > > If that is given,
> > > > >   then IDE's might configure themselves automatically without 

Re: [lang] Introduce @NonNull, and @Nullable

[sebb]

On Mon, 1 Feb 2021 at 17:56, Matt Sicker  wrote:
>
> Compile time annotations would only be necessary to build the commons
> component.

i.e. consumers of the source code would be required to provide the
annotations in some form.

This does not sound ideal.

> Unless they're runtime scope, but even that can work
> without class loader errors provided you're not reflecting on it.
>
> On Mon, 1 Feb 2021 at 11:45, sebb  wrote:
> >
> > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki  wrote:
> > >
> > > I like "javax.annotation namespace" too.
> > >
> > > Would you be willing to share more about why the annotation dependency
> > > should have "provided" scope? If a library (commons-lang) requires a
> > > dependency at runtime, I believe it should declare it as "compile"
> > > dependency.
> >
> > In either case, surely the user will have to provide the relevant
> > annotation jar in order to use the component?
> >
> > > In past, I did troubleshooting for
> > > missing javax.annotation.Nullable
> > > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917
> >
> > That link does not work; it ends up displaying the irrelevant issue:
> >
> > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-11730?filter=allissues
> >
> > The following link works better:
> > https://issues.apache.org/jira/browse/BEAM-8917
> >
> >
> > > On Mon, Feb 1, 2021 at 5:58 AM Jochen Wiedmann 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > as a followup to a discussion, that we had in August 2020, I'd like to
> > > > propose, that we introduce the @NonNull, and @Nullable annotations
> > > > into commons-lang.
> > > >
> > > > Since that discussion, I began to gradually introduce those
> > > > annotations into my own code. From that, I have learned three things:
> > > >
> > > >  1.) Although those annotations have RetentionPolicy.RUNTIME, they 
> > > > are
> > > > still
> > > >   invisible at runtime. In particular, they do not impose any
> > > > runtime requirements.
> > > >   We *can* use those annotations, but still remain a standalone
> > > > library.
> > > >  2.) There is no problem with mixed code: You can have some
> > > > classes, that use
> > > >   those annotations, while others don't. Or, to rephrase that:
> > > > Even, if the ultimate
> > > >   target should be, to use those annotations everywhere, they
> > > > can be introduced
> > > >   gradually on a per-class base. We can have the target as a
> > > > long time goal, but
> > > >   start small.
> > > >  3.) Although the annotations aren't present in the compiled code,
> > > > they still provide
> > > >   valuable information, if the source code is present in the
> > > > users IDE, because
> > > >   the user can quickly jump into the respective file. (IDE
> > > > support could be enhanced,
> > > >   for example Eclipse doesn't provide them as quick hints, but
> > > > that's something we
> > > >   can work on.
> > > >   Besides, static code analysis clearly *does* help (at least
> > > > in the current case) to
> > > >   avoid errors. In my opinion, we are the ones, who are
> > > > setting the standards in good
> > > >   code style, and this would clearly be an enhancement in that
> > > > area).
> > > >
> > > > So, assuming that my proposal should be accepted: How do we proceed? I
> > > > see two alternatives:
> > > >
> > > > a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> > > > "provided" to our dependencies. The scope will guarantee, that users
> > > > aren't affected at all.
> > > > b) We create our own annotations, say
> > > > org.apache.commons.lang3.annotations.NonNull, etc. When using
> > > > Spotbugs, or the respective IDE's, we need to adjust the namespace,
> > > > but that should be doable.
> > > >
> > > > Personally, I'm in favour of using the javax.annotation namespace, thus 
> > > > a).
> > > >
> > > > From my experiences, I conclude that we should also do the following:
> > > >
> > > > - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
> > > > a @NonNull result,
> > > >   because in practice, they are going to be used frequently. (In
> > > > cases, where the compiler
> > > >   doesn't understand, that a value is, in fact, not nullable.)
> > > > - Convince the maintainers of the maven-compiler-plugin, that use of
> > > > those annotations
> > > >   is something, that should be documented in the plugin configuration.
> > > > If that is given,
> > > >   then IDE's might configure themselves automatically without the need
> > > > for IDE specific
> > > >   files.
> > > >
> > > >
> > > > Jochen
> > > >
> > > >
> > > > 1.)
> > > >
> > > > --
> > > >
> > > > 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: 

Re: [lang] Introduce @NonNull, and @Nullable

[Matt Sicker]

Compile time annotations would only be necessary to build the commons
component. Unless they're runtime scope, but even that can work
without class loader errors provided you're not reflecting on it.

On Mon, 1 Feb 2021 at 11:45, sebb  wrote:
>
> On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki  wrote:
> >
> > I like "javax.annotation namespace" too.
> >
> > Would you be willing to share more about why the annotation dependency
> > should have "provided" scope? If a library (commons-lang) requires a
> > dependency at runtime, I believe it should declare it as "compile"
> > dependency.
>
> In either case, surely the user will have to provide the relevant
> annotation jar in order to use the component?
>
> > In past, I did troubleshooting for
> > missing javax.annotation.Nullable
> > https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917
>
> That link does not work; it ends up displaying the irrelevant issue:
>
> https://issues.apache.org/jira/projects/BEAM/issues/BEAM-11730?filter=allissues
>
> The following link works better:
> https://issues.apache.org/jira/browse/BEAM-8917
>
>
> > On Mon, Feb 1, 2021 at 5:58 AM Jochen Wiedmann 
> > wrote:
> >
> > > Hi,
> > >
> > > as a followup to a discussion, that we had in August 2020, I'd like to
> > > propose, that we introduce the @NonNull, and @Nullable annotations
> > > into commons-lang.
> > >
> > > Since that discussion, I began to gradually introduce those
> > > annotations into my own code. From that, I have learned three things:
> > >
> > >  1.) Although those annotations have RetentionPolicy.RUNTIME, they are
> > > still
> > >   invisible at runtime. In particular, they do not impose any
> > > runtime requirements.
> > >   We *can* use those annotations, but still remain a standalone
> > > library.
> > >  2.) There is no problem with mixed code: You can have some
> > > classes, that use
> > >   those annotations, while others don't. Or, to rephrase that:
> > > Even, if the ultimate
> > >   target should be, to use those annotations everywhere, they
> > > can be introduced
> > >   gradually on a per-class base. We can have the target as a
> > > long time goal, but
> > >   start small.
> > >  3.) Although the annotations aren't present in the compiled code,
> > > they still provide
> > >   valuable information, if the source code is present in the
> > > users IDE, because
> > >   the user can quickly jump into the respective file. (IDE
> > > support could be enhanced,
> > >   for example Eclipse doesn't provide them as quick hints, but
> > > that's something we
> > >   can work on.
> > >   Besides, static code analysis clearly *does* help (at least
> > > in the current case) to
> > >   avoid errors. In my opinion, we are the ones, who are
> > > setting the standards in good
> > >   code style, and this would clearly be an enhancement in that
> > > area).
> > >
> > > So, assuming that my proposal should be accepted: How do we proceed? I
> > > see two alternatives:
> > >
> > > a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> > > "provided" to our dependencies. The scope will guarantee, that users
> > > aren't affected at all.
> > > b) We create our own annotations, say
> > > org.apache.commons.lang3.annotations.NonNull, etc. When using
> > > Spotbugs, or the respective IDE's, we need to adjust the namespace,
> > > but that should be doable.
> > >
> > > Personally, I'm in favour of using the javax.annotation namespace, thus 
> > > a).
> > >
> > > From my experiences, I conclude that we should also do the following:
> > >
> > > - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
> > > a @NonNull result,
> > >   because in practice, they are going to be used frequently. (In
> > > cases, where the compiler
> > >   doesn't understand, that a value is, in fact, not nullable.)
> > > - Convince the maintainers of the maven-compiler-plugin, that use of
> > > those annotations
> > >   is something, that should be documented in the plugin configuration.
> > > If that is given,
> > >   then IDE's might configure themselves automatically without the need
> > > for IDE specific
> > >   files.
> > >
> > >
> > > Jochen
> > >
> > >
> > > 1.)
> > >
> > > --
> > >
> > > 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
> > >
> > >
> >
> > --
> > Regards,
> > Tomo
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To 

Re: [lang] Introduce @NonNull, and @Nullable

[sebb]

On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki  wrote:
>
> I like "javax.annotation namespace" too.
>
> Would you be willing to share more about why the annotation dependency
> should have "provided" scope? If a library (commons-lang) requires a
> dependency at runtime, I believe it should declare it as "compile"
> dependency.

In either case, surely the user will have to provide the relevant
annotation jar in order to use the component?

> In past, I did troubleshooting for
> missing javax.annotation.Nullable
> https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917

That link does not work; it ends up displaying the irrelevant issue:

https://issues.apache.org/jira/projects/BEAM/issues/BEAM-11730?filter=allissues

The following link works better:
https://issues.apache.org/jira/browse/BEAM-8917


> On Mon, Feb 1, 2021 at 5:58 AM Jochen Wiedmann 
> wrote:
>
> > Hi,
> >
> > as a followup to a discussion, that we had in August 2020, I'd like to
> > propose, that we introduce the @NonNull, and @Nullable annotations
> > into commons-lang.
> >
> > Since that discussion, I began to gradually introduce those
> > annotations into my own code. From that, I have learned three things:
> >
> >  1.) Although those annotations have RetentionPolicy.RUNTIME, they are
> > still
> >   invisible at runtime. In particular, they do not impose any
> > runtime requirements.
> >   We *can* use those annotations, but still remain a standalone
> > library.
> >  2.) There is no problem with mixed code: You can have some
> > classes, that use
> >   those annotations, while others don't. Or, to rephrase that:
> > Even, if the ultimate
> >   target should be, to use those annotations everywhere, they
> > can be introduced
> >   gradually on a per-class base. We can have the target as a
> > long time goal, but
> >   start small.
> >  3.) Although the annotations aren't present in the compiled code,
> > they still provide
> >   valuable information, if the source code is present in the
> > users IDE, because
> >   the user can quickly jump into the respective file. (IDE
> > support could be enhanced,
> >   for example Eclipse doesn't provide them as quick hints, but
> > that's something we
> >   can work on.
> >   Besides, static code analysis clearly *does* help (at least
> > in the current case) to
> >   avoid errors. In my opinion, we are the ones, who are
> > setting the standards in good
> >   code style, and this would clearly be an enhancement in that
> > area).
> >
> > So, assuming that my proposal should be accepted: How do we proceed? I
> > see two alternatives:
> >
> > a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> > "provided" to our dependencies. The scope will guarantee, that users
> > aren't affected at all.
> > b) We create our own annotations, say
> > org.apache.commons.lang3.annotations.NonNull, etc. When using
> > Spotbugs, or the respective IDE's, we need to adjust the namespace,
> > but that should be doable.
> >
> > Personally, I'm in favour of using the javax.annotation namespace, thus a).
> >
> > From my experiences, I conclude that we should also do the following:
> >
> > - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
> > a @NonNull result,
> >   because in practice, they are going to be used frequently. (In
> > cases, where the compiler
> >   doesn't understand, that a value is, in fact, not nullable.)
> > - Convince the maintainers of the maven-compiler-plugin, that use of
> > those annotations
> >   is something, that should be documented in the plugin configuration.
> > If that is given,
> >   then IDE's might configure themselves automatically without the need
> > for IDE specific
> >   files.
> >
> >
> > Jochen
> >
> >
> > 1.)
> >
> > --
> >
> > 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
> >
> >
>
> --
> Regards,
> Tomo

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Tomo Suzuki]

I like "javax.annotation namespace" too.

Would you be willing to share more about why the annotation dependency
should have "provided" scope? If a library (commons-lang) requires a
dependency at runtime, I believe it should declare it as "compile"
dependency. In past, I did troubleshooting for
missing javax.annotation.Nullable
https://issues.apache.org/jira/projects/BEAM/issues/BEAM-8917


On Mon, Feb 1, 2021 at 5:58 AM Jochen Wiedmann 
wrote:

> Hi,
>
> as a followup to a discussion, that we had in August 2020, I'd like to
> propose, that we introduce the @NonNull, and @Nullable annotations
> into commons-lang.
>
> Since that discussion, I began to gradually introduce those
> annotations into my own code. From that, I have learned three things:
>
>  1.) Although those annotations have RetentionPolicy.RUNTIME, they are
> still
>   invisible at runtime. In particular, they do not impose any
> runtime requirements.
>   We *can* use those annotations, but still remain a standalone
> library.
>  2.) There is no problem with mixed code: You can have some
> classes, that use
>   those annotations, while others don't. Or, to rephrase that:
> Even, if the ultimate
>   target should be, to use those annotations everywhere, they
> can be introduced
>   gradually on a per-class base. We can have the target as a
> long time goal, but
>   start small.
>  3.) Although the annotations aren't present in the compiled code,
> they still provide
>   valuable information, if the source code is present in the
> users IDE, because
>   the user can quickly jump into the respective file. (IDE
> support could be enhanced,
>   for example Eclipse doesn't provide them as quick hints, but
> that's something we
>   can work on.
>   Besides, static code analysis clearly *does* help (at least
> in the current case) to
>   avoid errors. In my opinion, we are the ones, who are
> setting the standards in good
>   code style, and this would clearly be an enhancement in that
> area).
>
> So, assuming that my proposal should be accepted: How do we proceed? I
> see two alternatives:
>
> a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> "provided" to our dependencies. The scope will guarantee, that users
> aren't affected at all.
> b) We create our own annotations, say
> org.apache.commons.lang3.annotations.NonNull, etc. When using
> Spotbugs, or the respective IDE's, we need to adjust the namespace,
> but that should be doable.
>
> Personally, I'm in favour of using the javax.annotation namespace, thus a).
>
> From my experiences, I conclude that we should also do the following:
>
> - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
> a @NonNull result,
>   because in practice, they are going to be used frequently. (In
> cases, where the compiler
>   doesn't understand, that a value is, in fact, not nullable.)
> - Convince the maintainers of the maven-compiler-plugin, that use of
> those annotations
>   is something, that should be documented in the plugin configuration.
> If that is given,
>   then IDE's might configure themselves automatically without the need
> for IDE specific
>   files.
>
>
> Jochen
>
>
> 1.)
>
> --
>
> 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
>
>

-- 
Regards,
Tomo

Re: [lang] Introduce @NonNull, and @Nullable

[sebb]

The ASF releases source.

Does the inclusion of these source annotations impose a burden on
people who download and compile our source?

On Mon, 1 Feb 2021 at 14:31, Julian Reschke  wrote:
>
> Am 01.02.2021 um 15:04 schrieb Gilles Sadowski:
> > Le lun. 1 févr. 2021 à 14:49, Jochen Wiedmann
> >  a écrit :
> >>
> >> On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory  wrote:
> >>
> >>> 1) Don't add and use custom annotations, this opens the door to each of 
> >>> our
> >>> 20+ components doing the same thing, so pick a library and stick with it.
> >>
> >> I suggested starting with lang, because that would be the template for
> >> most others. (At least those, who are already using lang as a
> >> dependency.)
> >>
> >>> 2) Make sure there are no licensing issues with that library.
> >>
> >> What licensing issues could there be with a dependency in scope
> >> "provided"? It is never going to be distributed,isn't it?
> >> Besides, the suggested library is available under ASL2:
> >> https://search.maven.org/artifact/com.google.code.findbugs/jsr305/3.0.2/jar
> >
> > Potential issues are mentioned there:
> >  https://dzone.com/articles/when-to-use-jsr-305-for-nullability-in-java
> >
> > This[1] may be especially worrying (?):
> > ---CUT---
> > Using jsr305 causes additional issues, if Guava is used in a modular
> > JDK9 applications, because it puts the annotations into
> > javax.annotation package, which is also used by a couple of other
> > JAR-s and a legacy JDK module java.xml.ws.annotation. If one wants to
> > create a modular JDK9 application with two dependencies to conflicting
> > JAR-s, Java refuses to compile and run it because of a package split.
> > [...]
> > Findbugs has been rebooted as Spotbugs and they are going to make a
> > switch from JSR-305 to their own internal annotations in version 4.0.0
> > that do not break anything [...]
> > ---CUT---
> > ...
>
> We started JSR-305 annotations in Jackrabbit Oak, and decided to remove
> them for exactly that reason. We migrated to the Jetbrains annotations
> instead. You may want to look at
>  and
> .
>
> Best regards, Julian
>
> -
> 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

Re: [lang] Introduce @NonNull, and @Nullable

[Julian Reschke]

Am 01.02.2021 um 15:04 schrieb Gilles Sadowski:

Le lun. 1 févr. 2021 à 14:49, Jochen Wiedmann
 a écrit :


On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory  wrote:


1) Don't add and use custom annotations, this opens the door to each of our
20+ components doing the same thing, so pick a library and stick with it.


I suggested starting with lang, because that would be the template for
most others. (At least those, who are already using lang as a
dependency.)


2) Make sure there are no licensing issues with that library.


What licensing issues could there be with a dependency in scope
"provided"? It is never going to be distributed,isn't it?
Besides, the suggested library is available under ASL2:
https://search.maven.org/artifact/com.google.code.findbugs/jsr305/3.0.2/jar


Potential issues are mentioned there:
 https://dzone.com/articles/when-to-use-jsr-305-for-nullability-in-java

This[1] may be especially worrying (?):
---CUT---
Using jsr305 causes additional issues, if Guava is used in a modular
JDK9 applications, because it puts the annotations into
javax.annotation package, which is also used by a couple of other
JAR-s and a legacy JDK module java.xml.ws.annotation. If one wants to
create a modular JDK9 application with two dependencies to conflicting
JAR-s, Java refuses to compile and run it because of a package split.
[...]
Findbugs has been rebooted as Spotbugs and they are going to make a
switch from JSR-305 to their own internal annotations in version 4.0.0
that do not break anything [...]
---CUT---
...


We started JSR-305 annotations in Jackrabbit Oak, and decided to remove
them for exactly that reason. We migrated to the Jetbrains annotations
instead. You may want to look at
 and
.

Best regards, Julian

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Emmanuel Bourg]

Le 01/02/2021 à 11:58, Jochen Wiedmann a écrit :

> So, assuming that my proposal should be accepted: How do we proceed? I
> see two alternatives:
> 
> a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> "provided" to our dependencies. The scope will guarantee, that users
> aren't affected at all.

+1, that's the dependency commonly used to provide these annotations.

> b) We create our own annotations, say
> org.apache.commons.lang3.annotations.NonNull, etc. When using
> Spotbugs, or the respective IDE's, we need to adjust the namespace,
> but that should be doable.

-1, we don't need more JSR305-like annotations in the Java ecosystem.

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Gilles Sadowski]

Le lun. 1 févr. 2021 à 14:49, Jochen Wiedmann
 a écrit :
>
> On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory  wrote:
>
> > 1) Don't add and use custom annotations, this opens the door to each of our
> > 20+ components doing the same thing, so pick a library and stick with it.
>
> I suggested starting with lang, because that would be the template for
> most others. (At least those, who are already using lang as a
> dependency.)
>
> > 2) Make sure there are no licensing issues with that library.
>
> What licensing issues could there be with a dependency in scope
> "provided"? It is never going to be distributed,isn't it?
> Besides, the suggested library is available under ASL2:
> https://search.maven.org/artifact/com.google.code.findbugs/jsr305/3.0.2/jar

Potential issues are mentioned there:
https://dzone.com/articles/when-to-use-jsr-305-for-nullability-in-java

This[1] may be especially worrying (?):
---CUT---
Using jsr305 causes additional issues, if Guava is used in a modular
JDK9 applications, because it puts the annotations into
javax.annotation package, which is also used by a couple of other
JAR-s and a legacy JDK module java.xml.ws.annotation. If one wants to
create a modular JDK9 application with two dependencies to conflicting
JAR-s, Java refuses to compile and run it because of a package split.
[...]
Findbugs has been rebooted as Spotbugs and they are going to make a
switch from JSR-305 to their own internal annotations in version 4.0.0
that do not break anything [...]
---CUT---

Regards,
Gilles

[1] https://github.com/google/guava/issues/2960#issue-263628666

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Gilles Sadowski]

Le lun. 1 févr. 2021 à 14:34, Gary Gregory  a écrit :
>
> My concerns are:
>
> 1) Don't add and use custom annotations, this opens the door to each of our
> 20+ components doing the same thing, so pick a library and stick with it.

+1

> 2) Make sure there are no licensing issues with that library.

Or create a "Commons" component for that specific purpose (?).

Gilles

> > [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Introduce @NonNull, and @Nullable

[Jochen Wiedmann]

On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory  wrote:

> 1) Don't add and use custom annotations, this opens the door to each of our
> 20+ components doing the same thing, so pick a library and stick with it.

I suggested starting with lang, because that would be the template for
most others. (At least those, who are already using lang as a
dependency.)

> 2) Make sure there are no licensing issues with that library.

What licensing issues could there be with a dependency in scope
"provided"? It is never going to be distributed,isn't it?
Besides, the suggested library is available under ASL2:
https://search.maven.org/artifact/com.google.code.findbugs/jsr305/3.0.2/jar

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

Re: [lang] Introduce @NonNull, and @Nullable

[Gary Gregory]

My concerns are:

1) Don't add and use custom annotations, this opens the door to each of our
20+ components doing the same thing, so pick a library and stick with it.

2) Make sure there are no licensing issues with that library.

Gary

On Mon, Feb 1, 2021, 05:58 Jochen Wiedmann 
wrote:

> Hi,
>
> as a followup to a discussion, that we had in August 2020, I'd like to
> propose, that we introduce the @NonNull, and @Nullable annotations
> into commons-lang.
>
> Since that discussion, I began to gradually introduce those
> annotations into my own code. From that, I have learned three things:
>
>  1.) Although those annotations have RetentionPolicy.RUNTIME, they are
> still
>   invisible at runtime. In particular, they do not impose any
> runtime requirements.
>   We *can* use those annotations, but still remain a standalone
> library.
>  2.) There is no problem with mixed code: You can have some
> classes, that use
>   those annotations, while others don't. Or, to rephrase that:
> Even, if the ultimate
>   target should be, to use those annotations everywhere, they
> can be introduced
>   gradually on a per-class base. We can have the target as a
> long time goal, but
>   start small.
>  3.) Although the annotations aren't present in the compiled code,
> they still provide
>   valuable information, if the source code is present in the
> users IDE, because
>   the user can quickly jump into the respective file. (IDE
> support could be enhanced,
>   for example Eclipse doesn't provide them as quick hints, but
> that's something we
>   can work on.
>   Besides, static code analysis clearly *does* help (at least
> in the current case) to
>   avoid errors. In my opinion, we are the ones, who are
> setting the standards in good
>   code style, and this would clearly be an enhancement in that
> area).
>
> So, assuming that my proposal should be accepted: How do we proceed? I
> see two alternatives:
>
> a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
> "provided" to our dependencies. The scope will guarantee, that users
> aren't affected at all.
> b) We create our own annotations, say
> org.apache.commons.lang3.annotations.NonNull, etc. When using
> Spotbugs, or the respective IDE's, we need to adjust the namespace,
> but that should be doable.
>
> Personally, I'm in favour of using the javax.annotation namespace, thus a).
>
> From my experiences, I conclude that we should also do the following:
>
> - Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
> a @NonNull result,
>   because in practice, they are going to be used frequently. (In
> cases, where the compiler
>   doesn't understand, that a value is, in fact, not nullable.)
> - Convince the maintainers of the maven-compiler-plugin, that use of
> those annotations
>   is something, that should be documented in the plugin configuration.
> If that is given,
>   then IDE's might configure themselves automatically without the need
> for IDE specific
>   files.
>
>
> Jochen
>
>
> 1.)
>
> --
>
> 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
>
>

Re: [lang] Introduce @NonNull, and @Nullable

[Bruno P. Kinoshita]

 Thanks for the explanation. Looks like it would be helpful for IDE/static 
analyzers/etc, without any impact for the users runtime.

I think a) makes sense, but b) would be OK too for me.

Cheers
Bruno



On Monday, 1 February 2021, 11:58:23 pm NZDT, Jochen Wiedmann 
 wrote:  
 
 Hi,

as a followup to a discussion, that we had in August 2020, I'd like to
propose, that we introduce the @NonNull, and @Nullable annotations
into commons-lang.

Since that discussion, I began to gradually introduce those
annotations into my own code. From that, I have learned three things:

    1.) Although those annotations have RetentionPolicy.RUNTIME, they are still
          invisible at runtime. In particular, they do not impose any
runtime requirements.
          We *can* use those annotations, but still remain a standalone library.
    2.) There is no problem with mixed code: You can have some
classes, that use
          those annotations, while others don't. Or, to rephrase that:
Even, if the ultimate
          target should be, to use those annotations everywhere, they
can be introduced
          gradually on a per-class base. We can have the target as a
long time goal, but
          start small.
    3.) Although the annotations aren't present in the compiled code,
they still provide
          valuable information, if the source code is present in the
users IDE, because
          the user can quickly jump into the respective file. (IDE
support could be enhanced,
          for example Eclipse doesn't provide them as quick hints, but
that's something we
          can work on.
          Besides, static code analysis clearly *does* help (at least
in the current case) to
          avoid errors. In my opinion, we are the ones, who are
setting the standards in good
          code style, and this would clearly be an enhancement in that area).

So, assuming that my proposal should be accepted: How do we proceed? I
see two alternatives:

a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
"provided" to our dependencies. The scope will guarantee, that users
aren't affected at all.
b) We create our own annotations, say
org.apache.commons.lang3.annotations.NonNull, etc. When using
Spotbugs, or the respective IDE's, we need to adjust the namespace,
but that should be doable.

Personally, I'm in favour of using the javax.annotation namespace, thus a).

>From my experiences, I conclude that we should also do the following:

- Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
a @NonNull result,
  because in practice, they are going to be used frequently. (In
cases, where the compiler
  doesn't understand, that a value is, in fact, not nullable.)
- Convince the maintainers of the maven-compiler-plugin, that use of
those annotations
  is something, that should be documented in the plugin configuration.
If that is given,
  then IDE's might configure themselves automatically without the need
for IDE specific
  files.


Jochen


1.)

-- 

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

  

[lang] Introduce @NonNull, and @Nullable

[Jochen Wiedmann]

Hi,

as a followup to a discussion, that we had in August 2020, I'd like to
propose, that we introduce the @NonNull, and @Nullable annotations
into commons-lang.

Since that discussion, I began to gradually introduce those
annotations into my own code. From that, I have learned three things:

 1.) Although those annotations have RetentionPolicy.RUNTIME, they are still
  invisible at runtime. In particular, they do not impose any
runtime requirements.
  We *can* use those annotations, but still remain a standalone library.
 2.) There is no problem with mixed code: You can have some
classes, that use
  those annotations, while others don't. Or, to rephrase that:
Even, if the ultimate
  target should be, to use those annotations everywhere, they
can be introduced
  gradually on a per-class base. We can have the target as a
long time goal, but
  start small.
 3.) Although the annotations aren't present in the compiled code,
they still provide
  valuable information, if the source code is present in the
users IDE, because
  the user can quickly jump into the respective file. (IDE
support could be enhanced,
  for example Eclipse doesn't provide them as quick hints, but
that's something we
  can work on.
  Besides, static code analysis clearly *does* help (at least
in the current case) to
  avoid errors. In my opinion, we are the ones, who are
setting the standards in good
  code style, and this would clearly be an enhancement in that area).

So, assuming that my proposal should be accepted: How do we proceed? I
see two alternatives:

a) We had com.google.code.findbugs:jsr305:3.0.2 with a scope
"provided" to our dependencies. The scope will guarantee, that users
aren't affected at all.
b) We create our own annotations, say
org.apache.commons.lang3.annotations.NonNull, etc. When using
Spotbugs, or the respective IDE's, we need to adjust the namespace,
but that should be doable.

Personally, I'm in favour of using the javax.annotation namespace, thus a).

>From my experiences, I conclude that we should also do the following:

- Change ObjectUtils.defaultIfNull, and ObjectUtils.getIfNull to have
a @NonNull result,
  because in practice, they are going to be used frequently. (In
cases, where the compiler
  doesn't understand, that a value is, in fact, not nullable.)
- Convince the maintainers of the maven-compiler-plugin, that use of
those annotations
  is something, that should be documented in the plugin configuration.
If that is given,
  then IDE's might configure themselves automatically without the need
for IDE specific
  files.


Jochen


1.)

-- 

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