You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2021/02/01 10:58:01 UTC
[lang] Introduce @NonNull, and @Nullable
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by th...@gmail.com.
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 simon@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Re: Re: [lang] Introduce @NonNull, and @Nullable
Posted by Xeno Amess <xe...@gmail.com>.
glad to hear about this.
this is what I always want...
I wished for this for months...
Gary Gregory <ga...@gmail.com> 于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 <se...@gmail.com> wrote:
>
> > On Mon, 15 Feb 2021 at 18:43, Gary Gregory <ga...@gmail.com>
> 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 <ta...@online.de>
> 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" <ga...@gmail.com>
> > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > > > I do not think we need a wiki since each project should have a Maven
> > > > generated page like
> > > > https://commons.apache.org/proper/commons-lang/dependencies.html
> > > >
> > > > Gary
> > > >
> > > >
> > > > On Mon, Feb 15, 2021 at 9:32 AM Thomas Schapitz <ta...@online.de>
> > wrote:
> > > >
> > > > > Oh, maybe I should pull more often...
> > > > > As far as I'm concerned, by all means, remove it, although I'm
> > probably
> > > > > the least one to call for that.
> > > > >
> > > > > And since we are at it: Are you aware of any explicit mentioning
> of a
> > > > > dependency policy wrt. commons?
> > > > > Maybe commons should set up some Wiki page, and start actively
> > managing
> > > > > that?
> > > > > A convenient place to point to, when discussions about that occur?
> > > > >
> > > > > Thomas
> > > > >
> > > > > Gesendet: Montag, 15. Februar 2021 um 14:38 Uhr
> > > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > > > This is already in Commons Lang master which is why I want to
> remove
> > it
> > > > > until there is a long term plan we can agree on.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <ta...@online.de>
> wrote:
> > > > >
> > > > > >
> > > > > > Short Answer: No, but Yes in the long term...
> > > > > >
> > > > > > Long Answer:
> > > > > > Originally, (as of February 1.) Jochen proposed to introduce them
> > into
> > > > > > commons-lang, with mixed results for the answers.
> > > > > > So i think they've not yet have made it into master, or do they?
> > > > > >
> > > > > > I rummaged through central, and of the modules to be found there
> > > > beneath
> > > > > > org/apache/commons there are just two, that actually reference
> the
> > > > > > com.google.code.finbugs:jsr305:jar, and both are maven plugins:
> The
> > > > > > commons-release-plugin and the commons-weaver-maven-plugin (not
> yet
> > > > > > checked, whether they do transitively so). So I guess, this
> isn't a
> > > > > > pressing issue for commons in general or lang specifically.
> > > > > >
> > > > > > I also take it, that commons always has been cautions not to
> light
> > > > > > heartedly introduce dependencies, and foreign dependencies at
> that,
> > > > into
> > > > > > its core modules lang, collections, math etc.
> > > > > >
> > > > > > If commons made it this far without jsr305, don't start
> introducing
> > > > this
> > > > > > doomed package now.
> > > > > >
> > > > > >
> > > > > > Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr
> > > > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > > > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > > > > > So... it is my impression now that we should remove these
> > annotations.
> > > > Is
> > > > > > that right?
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de>
> > > > wrote:
> > > > > >
> > > > > > > Not exactly, although that also seems, what the author of
> > > > > > >
> > > >
> >
> https://jspecify.dev/_sources/index.rst.txt[https://jspecify.dev/_sources/index.rst.txt]
> > > > is thinking.
> > > > > > > But given, that the last attempt at this went nowhere, and has
> > been
> > > > > > > abandoned about 10 years ago, I think it is rather unlikely,
> that
> > > > this
> > > > > > one
> > > > > > > would make the difference.
> > > > > > >
> > > > > > > And why should it be necessary for the user, to know the
> details
> > of
> > > > the
> > > > > > > interpretation of the checking framework?
> > > > > > > Annotations are kind of interfaces, and as such may be
> > interpreted
> > > > just
> > > > > > as
> > > > > > > any other interface as defining element of a contract, which
> > could be
> > > > > > > detailed in Javadoc. The same way as Eclipse Link and Hibernate
> > do
> > > > with
> > > > > > JPA
> > > > > > > annotations, while at least hibernate still also works with its
> > own
> > > > > > > annotations.
> > > > > > >
> > > > > > > In fact, @NotNull and its compannions can all be interpreted as
> > > > > > describing
> > > > > > > a predicate applying to certain elements of the source tree. So
> > all
> > > > > what
> > > > > > is
> > > > > > > needed, is to match the annotations with the predicates, the
> > > > framework
> > > > > > can
> > > > > > > support. The challenge is in the inference, when these
> > predicates are
> > > > > > > applied to the source tree.
> > > > > > >
> > > > > > > This way, a checker framework may take also advantage of the
> > > > knowledge
> > > > > > > hidden in foreign annotations: JPA, Hibernate, Jackson all have
> > > > > > constructs
> > > > > > > for indicating nullability and attribute sizes, that might be
> of
> > use.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> > > > > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > > > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > > > > > Isn't the root issue is that all toolchains need to agree on
> the
> > new
> > > > > > > annotations? What's that going to be?
> > > > > > >
> > > > > > > On Sun, Feb 7, 2021, 17:56 simon@ochsenreither.de <
> > > > > > simon@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-unsubscribe@commons.apache.org
> > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: Re: Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gary Gregory <ga...@gmail.com>.
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 <se...@gmail.com> wrote:
> On Mon, 15 Feb 2021 at 18:43, Gary Gregory <ga...@gmail.com> 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 <ta...@online.de> 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" <ga...@gmail.com>
> > > An: "Commons Developers List" <de...@commons.apache.org>
> > > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > > I do not think we need a wiki since each project should have a Maven
> > > generated page like
> > > https://commons.apache.org/proper/commons-lang/dependencies.html
> > >
> > > Gary
> > >
> > >
> > > On Mon, Feb 15, 2021 at 9:32 AM Thomas Schapitz <ta...@online.de>
> wrote:
> > >
> > > > Oh, maybe I should pull more often...
> > > > As far as I'm concerned, by all means, remove it, although I'm
> probably
> > > > the least one to call for that.
> > > >
> > > > And since we are at it: Are you aware of any explicit mentioning of a
> > > > dependency policy wrt. commons?
> > > > Maybe commons should set up some Wiki page, and start actively
> managing
> > > > that?
> > > > A convenient place to point to, when discussions about that occur?
> > > >
> > > > Thomas
> > > >
> > > > Gesendet: Montag, 15. Februar 2021 um 14:38 Uhr
> > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > > This is already in Commons Lang master which is why I want to remove
> it
> > > > until there is a long term plan we can agree on.
> > > >
> > > > Gary
> > > >
> > > > On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <ta...@online.de> wrote:
> > > >
> > > > >
> > > > > Short Answer: No, but Yes in the long term...
> > > > >
> > > > > Long Answer:
> > > > > Originally, (as of February 1.) Jochen proposed to introduce them
> into
> > > > > commons-lang, with mixed results for the answers.
> > > > > So i think they've not yet have made it into master, or do they?
> > > > >
> > > > > I rummaged through central, and of the modules to be found there
> > > beneath
> > > > > org/apache/commons there are just two, that actually reference the
> > > > > com.google.code.finbugs:jsr305:jar, and both are maven plugins: The
> > > > > commons-release-plugin and the commons-weaver-maven-plugin (not yet
> > > > > checked, whether they do transitively so). So I guess, this isn't a
> > > > > pressing issue for commons in general or lang specifically.
> > > > >
> > > > > I also take it, that commons always has been cautions not to light
> > > > > heartedly introduce dependencies, and foreign dependencies at that,
> > > into
> > > > > its core modules lang, collections, math etc.
> > > > >
> > > > > If commons made it this far without jsr305, don't start introducing
> > > this
> > > > > doomed package now.
> > > > >
> > > > >
> > > > > Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr
> > > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > > > > So... it is my impression now that we should remove these
> annotations.
> > > Is
> > > > > that right?
> > > > >
> > > > > Gary
> > > > >
> > > > > On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de>
> > > wrote:
> > > > >
> > > > > > Not exactly, although that also seems, what the author of
> > > > > >
> > >
> https://jspecify.dev/_sources/index.rst.txt[https://jspecify.dev/_sources/index.rst.txt]
> > > is thinking.
> > > > > > But given, that the last attempt at this went nowhere, and has
> been
> > > > > > abandoned about 10 years ago, I think it is rather unlikely, that
> > > this
> > > > > one
> > > > > > would make the difference.
> > > > > >
> > > > > > And why should it be necessary for the user, to know the details
> of
> > > the
> > > > > > interpretation of the checking framework?
> > > > > > Annotations are kind of interfaces, and as such may be
> interpreted
> > > just
> > > > > as
> > > > > > any other interface as defining element of a contract, which
> could be
> > > > > > detailed in Javadoc. The same way as Eclipse Link and Hibernate
> do
> > > with
> > > > > JPA
> > > > > > annotations, while at least hibernate still also works with its
> own
> > > > > > annotations.
> > > > > >
> > > > > > In fact, @NotNull and its compannions can all be interpreted as
> > > > > describing
> > > > > > a predicate applying to certain elements of the source tree. So
> all
> > > > what
> > > > > is
> > > > > > needed, is to match the annotations with the predicates, the
> > > framework
> > > > > can
> > > > > > support. The challenge is in the inference, when these
> predicates are
> > > > > > applied to the source tree.
> > > > > >
> > > > > > This way, a checker framework may take also advantage of the
> > > knowledge
> > > > > > hidden in foreign annotations: JPA, Hibernate, Jackson all have
> > > > > constructs
> > > > > > for indicating nullability and attribute sizes, that might be of
> use.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> > > > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > > > > Isn't the root issue is that all toolchains need to agree on the
> new
> > > > > > annotations? What's that going to be?
> > > > > >
> > > > > > On Sun, Feb 7, 2021, 17:56 simon@ochsenreither.de <
> > > > > simon@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-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Re: Re: [lang] Introduce @NonNull, and @Nullable
Posted by sebb <se...@gmail.com>.
On Mon, 15 Feb 2021 at 18:43, Gary Gregory <ga...@gmail.com> 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 <ta...@online.de> 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" <ga...@gmail.com>
> > An: "Commons Developers List" <de...@commons.apache.org>
> > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > I do not think we need a wiki since each project should have a Maven
> > generated page like
> > https://commons.apache.org/proper/commons-lang/dependencies.html
> >
> > Gary
> >
> >
> > On Mon, Feb 15, 2021 at 9:32 AM Thomas Schapitz <ta...@online.de> wrote:
> >
> > > Oh, maybe I should pull more often...
> > > As far as I'm concerned, by all means, remove it, although I'm probably
> > > the least one to call for that.
> > >
> > > And since we are at it: Are you aware of any explicit mentioning of a
> > > dependency policy wrt. commons?
> > > Maybe commons should set up some Wiki page, and start actively managing
> > > that?
> > > A convenient place to point to, when discussions about that occur?
> > >
> > > Thomas
> > >
> > > Gesendet: Montag, 15. Februar 2021 um 14:38 Uhr
> > > Von: "Gary Gregory" <ga...@gmail.com>
> > > An: "Commons Developers List" <de...@commons.apache.org>
> > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > This is already in Commons Lang master which is why I want to remove it
> > > until there is a long term plan we can agree on.
> > >
> > > Gary
> > >
> > > On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <ta...@online.de> wrote:
> > >
> > > >
> > > > Short Answer: No, but Yes in the long term...
> > > >
> > > > Long Answer:
> > > > Originally, (as of February 1.) Jochen proposed to introduce them into
> > > > commons-lang, with mixed results for the answers.
> > > > So i think they've not yet have made it into master, or do they?
> > > >
> > > > I rummaged through central, and of the modules to be found there
> > beneath
> > > > org/apache/commons there are just two, that actually reference the
> > > > com.google.code.finbugs:jsr305:jar, and both are maven plugins: The
> > > > commons-release-plugin and the commons-weaver-maven-plugin (not yet
> > > > checked, whether they do transitively so). So I guess, this isn't a
> > > > pressing issue for commons in general or lang specifically.
> > > >
> > > > I also take it, that commons always has been cautions not to light
> > > > heartedly introduce dependencies, and foreign dependencies at that,
> > into
> > > > its core modules lang, collections, math etc.
> > > >
> > > > If commons made it this far without jsr305, don't start introducing
> > this
> > > > doomed package now.
> > > >
> > > >
> > > > Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr
> > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > > > So... it is my impression now that we should remove these annotations.
> > Is
> > > > that right?
> > > >
> > > > Gary
> > > >
> > > > On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de>
> > wrote:
> > > >
> > > > > Not exactly, although that also seems, what the author of
> > > > >
> > https://jspecify.dev/_sources/index.rst.txt[https://jspecify.dev/_sources/index.rst.txt]
> > is thinking.
> > > > > But given, that the last attempt at this went nowhere, and has been
> > > > > abandoned about 10 years ago, I think it is rather unlikely, that
> > this
> > > > one
> > > > > would make the difference.
> > > > >
> > > > > And why should it be necessary for the user, to know the details of
> > the
> > > > > interpretation of the checking framework?
> > > > > Annotations are kind of interfaces, and as such may be interpreted
> > just
> > > > as
> > > > > any other interface as defining element of a contract, which could be
> > > > > detailed in Javadoc. The same way as Eclipse Link and Hibernate do
> > with
> > > > JPA
> > > > > annotations, while at least hibernate still also works with its own
> > > > > annotations.
> > > > >
> > > > > In fact, @NotNull and its compannions can all be interpreted as
> > > > describing
> > > > > a predicate applying to certain elements of the source tree. So all
> > > what
> > > > is
> > > > > needed, is to match the annotations with the predicates, the
> > framework
> > > > can
> > > > > support. The challenge is in the inference, when these predicates are
> > > > > applied to the source tree.
> > > > >
> > > > > This way, a checker framework may take also advantage of the
> > knowledge
> > > > > hidden in foreign annotations: JPA, Hibernate, Jackson all have
> > > > constructs
> > > > > for indicating nullability and attribute sizes, that might be of use.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> > > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > > > Isn't the root issue is that all toolchains need to agree on the new
> > > > > annotations? What's that going to be?
> > > > >
> > > > > On Sun, Feb 7, 2021, 17:56 simon@ochsenreither.de <
> > > > simon@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-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Re: Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gary Gregory <ga...@gmail.com>.
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 <ta...@online.de> 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" <ga...@gmail.com>
> An: "Commons Developers List" <de...@commons.apache.org>
> Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> I do not think we need a wiki since each project should have a Maven
> generated page like
> https://commons.apache.org/proper/commons-lang/dependencies.html
>
> Gary
>
>
> On Mon, Feb 15, 2021 at 9:32 AM Thomas Schapitz <ta...@online.de> wrote:
>
> > Oh, maybe I should pull more often...
> > As far as I'm concerned, by all means, remove it, although I'm probably
> > the least one to call for that.
> >
> > And since we are at it: Are you aware of any explicit mentioning of a
> > dependency policy wrt. commons?
> > Maybe commons should set up some Wiki page, and start actively managing
> > that?
> > A convenient place to point to, when discussions about that occur?
> >
> > Thomas
> >
> > Gesendet: Montag, 15. Februar 2021 um 14:38 Uhr
> > Von: "Gary Gregory" <ga...@gmail.com>
> > An: "Commons Developers List" <de...@commons.apache.org>
> > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > This is already in Commons Lang master which is why I want to remove it
> > until there is a long term plan we can agree on.
> >
> > Gary
> >
> > On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <ta...@online.de> wrote:
> >
> > >
> > > Short Answer: No, but Yes in the long term...
> > >
> > > Long Answer:
> > > Originally, (as of February 1.) Jochen proposed to introduce them into
> > > commons-lang, with mixed results for the answers.
> > > So i think they've not yet have made it into master, or do they?
> > >
> > > I rummaged through central, and of the modules to be found there
> beneath
> > > org/apache/commons there are just two, that actually reference the
> > > com.google.code.finbugs:jsr305:jar, and both are maven plugins: The
> > > commons-release-plugin and the commons-weaver-maven-plugin (not yet
> > > checked, whether they do transitively so). So I guess, this isn't a
> > > pressing issue for commons in general or lang specifically.
> > >
> > > I also take it, that commons always has been cautions not to light
> > > heartedly introduce dependencies, and foreign dependencies at that,
> into
> > > its core modules lang, collections, math etc.
> > >
> > > If commons made it this far without jsr305, don't start introducing
> this
> > > doomed package now.
> > >
> > >
> > > Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr
> > > Von: "Gary Gregory" <ga...@gmail.com>
> > > An: "Commons Developers List" <de...@commons.apache.org>
> > > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > > So... it is my impression now that we should remove these annotations.
> Is
> > > that right?
> > >
> > > Gary
> > >
> > > On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de>
> wrote:
> > >
> > > > Not exactly, although that also seems, what the author of
> > > >
> https://jspecify.dev/_sources/index.rst.txt[https://jspecify.dev/_sources/index.rst.txt]
> is thinking.
> > > > But given, that the last attempt at this went nowhere, and has been
> > > > abandoned about 10 years ago, I think it is rather unlikely, that
> this
> > > one
> > > > would make the difference.
> > > >
> > > > And why should it be necessary for the user, to know the details of
> the
> > > > interpretation of the checking framework?
> > > > Annotations are kind of interfaces, and as such may be interpreted
> just
> > > as
> > > > any other interface as defining element of a contract, which could be
> > > > detailed in Javadoc. The same way as Eclipse Link and Hibernate do
> with
> > > JPA
> > > > annotations, while at least hibernate still also works with its own
> > > > annotations.
> > > >
> > > > In fact, @NotNull and its compannions can all be interpreted as
> > > describing
> > > > a predicate applying to certain elements of the source tree. So all
> > what
> > > is
> > > > needed, is to match the annotations with the predicates, the
> framework
> > > can
> > > > support. The challenge is in the inference, when these predicates are
> > > > applied to the source tree.
> > > >
> > > > This way, a checker framework may take also advantage of the
> knowledge
> > > > hidden in foreign annotations: JPA, Hibernate, Jackson all have
> > > constructs
> > > > for indicating nullability and attribute sizes, that might be of use.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> > > > Von: "Gary Gregory" <ga...@gmail.com>
> > > > An: "Commons Developers List" <de...@commons.apache.org>
> > > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > > Isn't the root issue is that all toolchains need to agree on the new
> > > > annotations? What's that going to be?
> > > >
> > > > On Sun, Feb 7, 2021, 17:56 simon@ochsenreither.de <
> > > simon@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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Aw: Re: Re: [lang] Introduce @NonNull, and @Nullable
Posted by Thomas Schapitz <ta...@online.de>.
... 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" <ga...@gmail.com>
An: "Commons Developers List" <de...@commons.apache.org>
Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
I do not think we need a wiki since each project should have a Maven
generated page like
https://commons.apache.org/proper/commons-lang/dependencies.html
Gary
On Mon, Feb 15, 2021 at 9:32 AM Thomas Schapitz <ta...@online.de> wrote:
> Oh, maybe I should pull more often...
> As far as I'm concerned, by all means, remove it, although I'm probably
> the least one to call for that.
>
> And since we are at it: Are you aware of any explicit mentioning of a
> dependency policy wrt. commons?
> Maybe commons should set up some Wiki page, and start actively managing
> that?
> A convenient place to point to, when discussions about that occur?
>
> Thomas
>
> Gesendet: Montag, 15. Februar 2021 um 14:38 Uhr
> Von: "Gary Gregory" <ga...@gmail.com>
> An: "Commons Developers List" <de...@commons.apache.org>
> Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> This is already in Commons Lang master which is why I want to remove it
> until there is a long term plan we can agree on.
>
> Gary
>
> On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <ta...@online.de> wrote:
>
> >
> > Short Answer: No, but Yes in the long term...
> >
> > Long Answer:
> > Originally, (as of February 1.) Jochen proposed to introduce them into
> > commons-lang, with mixed results for the answers.
> > So i think they've not yet have made it into master, or do they?
> >
> > I rummaged through central, and of the modules to be found there beneath
> > org/apache/commons there are just two, that actually reference the
> > com.google.code.finbugs:jsr305:jar, and both are maven plugins: The
> > commons-release-plugin and the commons-weaver-maven-plugin (not yet
> > checked, whether they do transitively so). So I guess, this isn't a
> > pressing issue for commons in general or lang specifically.
> >
> > I also take it, that commons always has been cautions not to light
> > heartedly introduce dependencies, and foreign dependencies at that, into
> > its core modules lang, collections, math etc.
> >
> > If commons made it this far without jsr305, don't start introducing this
> > doomed package now.
> >
> >
> > Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr
> > Von: "Gary Gregory" <ga...@gmail.com>
> > An: "Commons Developers List" <de...@commons.apache.org>
> > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > So... it is my impression now that we should remove these annotations. Is
> > that right?
> >
> > Gary
> >
> > On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de> wrote:
> >
> > > Not exactly, although that also seems, what the author of
> > > https://jspecify.dev/_sources/index.rst.txt[https://jspecify.dev/_sources/index.rst.txt] is thinking.
> > > But given, that the last attempt at this went nowhere, and has been
> > > abandoned about 10 years ago, I think it is rather unlikely, that this
> > one
> > > would make the difference.
> > >
> > > And why should it be necessary for the user, to know the details of the
> > > interpretation of the checking framework?
> > > Annotations are kind of interfaces, and as such may be interpreted just
> > as
> > > any other interface as defining element of a contract, which could be
> > > detailed in Javadoc. The same way as Eclipse Link and Hibernate do with
> > JPA
> > > annotations, while at least hibernate still also works with its own
> > > annotations.
> > >
> > > In fact, @NotNull and its compannions can all be interpreted as
> > describing
> > > a predicate applying to certain elements of the source tree. So all
> what
> > is
> > > needed, is to match the annotations with the predicates, the framework
> > can
> > > support. The challenge is in the inference, when these predicates are
> > > applied to the source tree.
> > >
> > > This way, a checker framework may take also advantage of the knowledge
> > > hidden in foreign annotations: JPA, Hibernate, Jackson all have
> > constructs
> > > for indicating nullability and attribute sizes, that might be of use.
> > >
> > >
> > >
> > >
> > >
> > > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> > > Von: "Gary Gregory" <ga...@gmail.com>
> > > An: "Commons Developers List" <de...@commons.apache.org>
> > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > Isn't the root issue is that all toolchains need to agree on the new
> > > annotations? What's that going to be?
> > >
> > > On Sun, Feb 7, 2021, 17:56 simon@ochsenreither.de <
> > simon@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gary Gregory <ga...@gmail.com>.
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 <ta...@online.de> wrote:
> Oh, maybe I should pull more often...
> As far as I'm concerned, by all means, remove it, although I'm probably
> the least one to call for that.
>
> And since we are at it: Are you aware of any explicit mentioning of a
> dependency policy wrt. commons?
> Maybe commons should set up some Wiki page, and start actively managing
> that?
> A convenient place to point to, when discussions about that occur?
>
> Thomas
>
> Gesendet: Montag, 15. Februar 2021 um 14:38 Uhr
> Von: "Gary Gregory" <ga...@gmail.com>
> An: "Commons Developers List" <de...@commons.apache.org>
> Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> This is already in Commons Lang master which is why I want to remove it
> until there is a long term plan we can agree on.
>
> Gary
>
> On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <ta...@online.de> wrote:
>
> >
> > Short Answer: No, but Yes in the long term...
> >
> > Long Answer:
> > Originally, (as of February 1.) Jochen proposed to introduce them into
> > commons-lang, with mixed results for the answers.
> > So i think they've not yet have made it into master, or do they?
> >
> > I rummaged through central, and of the modules to be found there beneath
> > org/apache/commons there are just two, that actually reference the
> > com.google.code.finbugs:jsr305:jar, and both are maven plugins: The
> > commons-release-plugin and the commons-weaver-maven-plugin (not yet
> > checked, whether they do transitively so). So I guess, this isn't a
> > pressing issue for commons in general or lang specifically.
> >
> > I also take it, that commons always has been cautions not to light
> > heartedly introduce dependencies, and foreign dependencies at that, into
> > its core modules lang, collections, math etc.
> >
> > If commons made it this far without jsr305, don't start introducing this
> > doomed package now.
> >
> >
> > Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr
> > Von: "Gary Gregory" <ga...@gmail.com>
> > An: "Commons Developers List" <de...@commons.apache.org>
> > Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> > So... it is my impression now that we should remove these annotations. Is
> > that right?
> >
> > Gary
> >
> > On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de> wrote:
> >
> > > Not exactly, although that also seems, what the author of
> > > https://jspecify.dev/_sources/index.rst.txt is thinking.
> > > But given, that the last attempt at this went nowhere, and has been
> > > abandoned about 10 years ago, I think it is rather unlikely, that this
> > one
> > > would make the difference.
> > >
> > > And why should it be necessary for the user, to know the details of the
> > > interpretation of the checking framework?
> > > Annotations are kind of interfaces, and as such may be interpreted just
> > as
> > > any other interface as defining element of a contract, which could be
> > > detailed in Javadoc. The same way as Eclipse Link and Hibernate do with
> > JPA
> > > annotations, while at least hibernate still also works with its own
> > > annotations.
> > >
> > > In fact, @NotNull and its compannions can all be interpreted as
> > describing
> > > a predicate applying to certain elements of the source tree. So all
> what
> > is
> > > needed, is to match the annotations with the predicates, the framework
> > can
> > > support. The challenge is in the inference, when these predicates are
> > > applied to the source tree.
> > >
> > > This way, a checker framework may take also advantage of the knowledge
> > > hidden in foreign annotations: JPA, Hibernate, Jackson all have
> > constructs
> > > for indicating nullability and attribute sizes, that might be of use.
> > >
> > >
> > >
> > >
> > >
> > > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> > > Von: "Gary Gregory" <ga...@gmail.com>
> > > An: "Commons Developers List" <de...@commons.apache.org>
> > > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > > Isn't the root issue is that all toolchains need to agree on the new
> > > annotations? What's that going to be?
> > >
> > > On Sun, Feb 7, 2021, 17:56 simon@ochsenreither.de <
> > simon@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Aw: Re: [lang] Introduce @NonNull, and @Nullable
Posted by Thomas Schapitz <ta...@online.de>.
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" <ga...@gmail.com>
An: "Commons Developers List" <de...@commons.apache.org>
Betreff: Re: [lang] Introduce @NonNull, and @Nullable
This is already in Commons Lang master which is why I want to remove it
until there is a long term plan we can agree on.
Gary
On Mon, Feb 15, 2021, 07:38 Thomas Schapitz <ta...@online.de> wrote:
>
> Short Answer: No, but Yes in the long term...
>
> Long Answer:
> Originally, (as of February 1.) Jochen proposed to introduce them into
> commons-lang, with mixed results for the answers.
> So i think they've not yet have made it into master, or do they?
>
> I rummaged through central, and of the modules to be found there beneath
> org/apache/commons there are just two, that actually reference the
> com.google.code.finbugs:jsr305:jar, and both are maven plugins: The
> commons-release-plugin and the commons-weaver-maven-plugin (not yet
> checked, whether they do transitively so). So I guess, this isn't a
> pressing issue for commons in general or lang specifically.
>
> I also take it, that commons always has been cautions not to light
> heartedly introduce dependencies, and foreign dependencies at that, into
> its core modules lang, collections, math etc.
>
> If commons made it this far without jsr305, don't start introducing this
> doomed package now.
>
>
> Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr
> Von: "Gary Gregory" <ga...@gmail.com>
> An: "Commons Developers List" <de...@commons.apache.org>
> Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> So... it is my impression now that we should remove these annotations. Is
> that right?
>
> Gary
>
> On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de> wrote:
>
> > Not exactly, although that also seems, what the author of
> > https://jspecify.dev/_sources/index.rst.txt is thinking.
> > But given, that the last attempt at this went nowhere, and has been
> > abandoned about 10 years ago, I think it is rather unlikely, that this
> one
> > would make the difference.
> >
> > And why should it be necessary for the user, to know the details of the
> > interpretation of the checking framework?
> > Annotations are kind of interfaces, and as such may be interpreted just
> as
> > any other interface as defining element of a contract, which could be
> > detailed in Javadoc. The same way as Eclipse Link and Hibernate do with
> JPA
> > annotations, while at least hibernate still also works with its own
> > annotations.
> >
> > In fact, @NotNull and its compannions can all be interpreted as
> describing
> > a predicate applying to certain elements of the source tree. So all what
> is
> > needed, is to match the annotations with the predicates, the framework
> can
> > support. The challenge is in the inference, when these predicates are
> > applied to the source tree.
> >
> > This way, a checker framework may take also advantage of the knowledge
> > hidden in foreign annotations: JPA, Hibernate, Jackson all have
> constructs
> > for indicating nullability and attribute sizes, that might be of use.
> >
> >
> >
> >
> >
> > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> > Von: "Gary Gregory" <ga...@gmail.com>
> > An: "Commons Developers List" <de...@commons.apache.org>
> > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > Isn't the root issue is that all toolchains need to agree on the new
> > annotations? What's that going to be?
> >
> > On Sun, Feb 7, 2021, 17:56 simon@ochsenreither.de <
> simon@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gary Gregory <ga...@gmail.com>.
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 <ta...@online.de> wrote:
>
> Short Answer: No, but Yes in the long term...
>
> Long Answer:
> Originally, (as of February 1.) Jochen proposed to introduce them into
> commons-lang, with mixed results for the answers.
> So i think they've not yet have made it into master, or do they?
>
> I rummaged through central, and of the modules to be found there beneath
> org/apache/commons there are just two, that actually reference the
> com.google.code.finbugs:jsr305:jar, and both are maven plugins: The
> commons-release-plugin and the commons-weaver-maven-plugin (not yet
> checked, whether they do transitively so). So I guess, this isn't a
> pressing issue for commons in general or lang specifically.
>
> I also take it, that commons always has been cautions not to light
> heartedly introduce dependencies, and foreign dependencies at that, into
> its core modules lang, collections, math etc.
>
> If commons made it this far without jsr305, don't start introducing this
> doomed package now.
>
>
> Gesendet: Samstag, 13. Februar 2021 um 21:13 Uhr
> Von: "Gary Gregory" <ga...@gmail.com>
> An: "Commons Developers List" <de...@commons.apache.org>
> Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
> So... it is my impression now that we should remove these annotations. Is
> that right?
>
> Gary
>
> On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de> wrote:
>
> > Not exactly, although that also seems, what the author of
> > https://jspecify.dev/_sources/index.rst.txt is thinking.
> > But given, that the last attempt at this went nowhere, and has been
> > abandoned about 10 years ago, I think it is rather unlikely, that this
> one
> > would make the difference.
> >
> > And why should it be necessary for the user, to know the details of the
> > interpretation of the checking framework?
> > Annotations are kind of interfaces, and as such may be interpreted just
> as
> > any other interface as defining element of a contract, which could be
> > detailed in Javadoc. The same way as Eclipse Link and Hibernate do with
> JPA
> > annotations, while at least hibernate still also works with its own
> > annotations.
> >
> > In fact, @NotNull and its compannions can all be interpreted as
> describing
> > a predicate applying to certain elements of the source tree. So all what
> is
> > needed, is to match the annotations with the predicates, the framework
> can
> > support. The challenge is in the inference, when these predicates are
> > applied to the source tree.
> >
> > This way, a checker framework may take also advantage of the knowledge
> > hidden in foreign annotations: JPA, Hibernate, Jackson all have
> constructs
> > for indicating nullability and attribute sizes, that might be of use.
> >
> >
> >
> >
> >
> > Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> > Von: "Gary Gregory" <ga...@gmail.com>
> > An: "Commons Developers List" <de...@commons.apache.org>
> > Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> > Isn't the root issue is that all toolchains need to agree on the new
> > annotations? What's that going to be?
> >
> > On Sun, Feb 7, 2021, 17:56 simon@ochsenreither.de <
> simon@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Thomas Schapitz <ta...@online.de>.
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" <ga...@gmail.com>
An: "Commons Developers List" <de...@commons.apache.org>
Betreff: Re: Re: [lang] Introduce @NonNull, and @Nullable
So... it is my impression now that we should remove these annotations. Is
that right?
Gary
On Fri, Feb 12, 2021 at 6:28 PM Thomas Schapitz <ta...@online.de> wrote:
> Not exactly, although that also seems, what the author of
> https://jspecify.dev/_sources/index.rst.txt is thinking.
> But given, that the last attempt at this went nowhere, and has been
> abandoned about 10 years ago, I think it is rather unlikely, that this one
> would make the difference.
>
> And why should it be necessary for the user, to know the details of the
> interpretation of the checking framework?
> Annotations are kind of interfaces, and as such may be interpreted just as
> any other interface as defining element of a contract, which could be
> detailed in Javadoc. The same way as Eclipse Link and Hibernate do with JPA
> annotations, while at least hibernate still also works with its own
> annotations.
>
> In fact, @NotNull and its compannions can all be interpreted as describing
> a predicate applying to certain elements of the source tree. So all what is
> needed, is to match the annotations with the predicates, the framework can
> support. The challenge is in the inference, when these predicates are
> applied to the source tree.
>
> This way, a checker framework may take also advantage of the knowledge
> hidden in foreign annotations: JPA, Hibernate, Jackson all have constructs
> for indicating nullability and attribute sizes, that might be of use.
>
>
>
>
>
> Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> Von: "Gary Gregory" <ga...@gmail.com>
> An: "Commons Developers List" <de...@commons.apache.org>
> Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> Isn't the root issue is that all toolchains need to agree on the new
> annotations? What's that going to be?
>
> On Sun, Feb 7, 2021, 17:56 simon@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gary Gregory <ga...@gmail.com>.
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 <ta...@online.de> wrote:
> Not exactly, although that also seems, what the author of
> https://jspecify.dev/_sources/index.rst.txt is thinking.
> But given, that the last attempt at this went nowhere, and has been
> abandoned about 10 years ago, I think it is rather unlikely, that this one
> would make the difference.
>
> And why should it be necessary for the user, to know the details of the
> interpretation of the checking framework?
> Annotations are kind of interfaces, and as such may be interpreted just as
> any other interface as defining element of a contract, which could be
> detailed in Javadoc. The same way as Eclipse Link and Hibernate do with JPA
> annotations, while at least hibernate still also works with its own
> annotations.
>
> In fact, @NotNull and its compannions can all be interpreted as describing
> a predicate applying to certain elements of the source tree. So all what is
> needed, is to match the annotations with the predicates, the framework can
> support. The challenge is in the inference, when these predicates are
> applied to the source tree.
>
> This way, a checker framework may take also advantage of the knowledge
> hidden in foreign annotations: JPA, Hibernate, Jackson all have constructs
> for indicating nullability and attribute sizes, that might be of use.
>
>
>
>
>
> Gesendet: Montag, 08. Februar 2021 um 00:37 Uhr
> Von: "Gary Gregory" <ga...@gmail.com>
> An: "Commons Developers List" <de...@commons.apache.org>
> Betreff: Re: [lang] Introduce @NonNull, and @Nullable
> Isn't the root issue is that all toolchains need to agree on the new
> annotations? What's that going to be?
>
> On Sun, Feb 7, 2021, 17:56 simon@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Aw: Re: [lang] Introduce @NonNull, and @Nullable
Posted by Thomas Schapitz <ta...@online.de>.
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" <ga...@gmail.com>
An: "Commons Developers List" <de...@commons.apache.org>
Betreff: Re: [lang] Introduce @NonNull, and @Nullable
Isn't the root issue is that all toolchains need to agree on the new
annotations? What's that going to be?
On Sun, Feb 7, 2021, 17:56 simon@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gary Gregory <ga...@gmail.com>.
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 simon@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
>
Re: [lang] Introduce @NonNull, and @Nullable
Posted by si...@ochsenreither.de,
si...@ochsenreither.de.
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
Posted by Thomas <ta...@online.de>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by sebb <se...@gmail.com>.
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 <ju...@gmx.de> wrote:
>
> Am 01.02.2021 um 15:04 schrieb Gilles Sadowski:
> > Le lun. 1 févr. 2021 à 14:49, Jochen Wiedmann
> > <jo...@gmail.com> a écrit :
> >>
> >> On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory <ga...@gmail.com> 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
> <https://issues.apache.org/jira/browse/JCR-4301> and
> <https://issues.apache.org/jira/browse/OAK-7511>.
>
> Best regards, Julian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Julian Reschke <ju...@gmx.de>.
Am 01.02.2021 um 15:04 schrieb Gilles Sadowski:
> Le lun. 1 févr. 2021 à 14:49, Jochen Wiedmann
> <jo...@gmail.com> a écrit :
>>
>> On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory <ga...@gmail.com> 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
<https://issues.apache.org/jira/browse/JCR-4301> and
<https://issues.apache.org/jira/browse/OAK-7511>.
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gilles Sadowski <gi...@gmail.com>.
Le lun. 1 févr. 2021 à 14:49, Jochen Wiedmann
<jo...@gmail.com> a écrit :
>
> On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory <ga...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Mon, Feb 1, 2021 at 2:34 PM Gary Gregory <ga...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gilles Sadowski <gi...@gmail.com>.
Le lun. 1 févr. 2021 à 14:34, Gary Gregory <ga...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gary Gregory <ga...@gmail.com>.
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 <jo...@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 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang] Introduce @NonNull, and @Nullable
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
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 <jo...@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 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Emmanuel Bourg <eb...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Jochen Wiedmann <jo...@apache.org>.
On 2021/02/02 08:10:33, Julian Reschke <ju...@gmx.de> wrote:
> Please see <https://nipafx.dev/jsr-305-java-9/>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Julian Reschke <ju...@gmx.de>.
Am 01.02.2021 um 17:45 schrieb Tomo Suzuki:
> I like "javax.annotation namespace" too.
> ...
Please see <https://nipafx.dev/jsr-305-java-9/>.
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Jochen Wiedmann <jo...@apache.org>.
On 2021/02/01 16:45:46, Tomo Suzuki <su...@google.com.INVALID> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
AW: [lang] Introduce @NonNull, and @Nullable
Posted by BU...@vhv.de.
+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 <bo...@gmail.com>
Gesendet: Dienstag, 2. Februar 2021 17:35
An: Commons Developers List <de...@commons.apache.org>
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Matt Sicker <bo...@gmail.com>.
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 <se...@gmail.com> wrote:
>
> On Mon, 1 Feb 2021 at 22:39, Gary Gregory <ga...@gmail.com> 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 <se...@gmail.com> wrote:
> >
> > > On Mon, 1 Feb 2021 at 17:56, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
> > > > >
> > > > > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki <su...@google.com.invalid>
> > > 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.wiedmann@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 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-unsubscribe@commons.apache.org
> > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Tomo
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Matt Sicker <bo...@gmail.com>.
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 <se...@gmail.com> wrote:
>
> On Thu, 4 Feb 2021 at 20:28, Jochen Wiedmann <jo...@apache.org> wrote:
> >
> >
> >
> > On 2021/02/02 11:34:09, sebb <se...@gmail.com> 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by sebb <se...@gmail.com>.
On Thu, 4 Feb 2021 at 20:28, Jochen Wiedmann <jo...@apache.org> wrote:
>
>
>
> On 2021/02/02 11:34:09, sebb <se...@gmail.com> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Jochen Wiedmann <jo...@apache.org>.
On 2021/02/02 11:34:09, sebb <se...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by sebb <se...@gmail.com>.
On Mon, 1 Feb 2021 at 22:39, Gary Gregory <ga...@gmail.com> 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 <se...@gmail.com> wrote:
>
> > On Mon, 1 Feb 2021 at 17:56, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
> > > >
> > > > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki <su...@google.com.invalid>
> > 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.wiedmann@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 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-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Tomo
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Gary Gregory <ga...@gmail.com>.
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 <se...@gmail.com> wrote:
> On Mon, 1 Feb 2021 at 17:56, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
> > >
> > > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki <su...@google.com.invalid>
> 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.wiedmann@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 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-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > > >
> > > >
> > > > --
> > > > Regards,
> > > > Tomo
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang] Introduce @NonNull, and @Nullable
Posted by sebb <se...@gmail.com>.
On Mon, 1 Feb 2021 at 17:56, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
> >
> > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki <su...@google.com.invalid> 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 <jo...@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 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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > > --
> > > Regards,
> > > Tomo
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Tomo Suzuki <su...@google.com.INVALID>.
Sebb and Matt,
Thank you for clarification. Yes, then provided scope makes sense. (I now
remember that in my issue a class was referencing Nullable.)
Thanks,
Tomo
On Mon, Feb 1, 2021 at 12:56 Matt Sicker <bo...@gmail.com> wrote:
> 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 <se...@gmail.com> wrote:
> >
> > On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki <su...@google.com.invalid>
> 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.wiedmann@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 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-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >
> > >
> > > --
> > > Regards,
> > > Tomo
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
Regards,
Tomo
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Matt Sicker <bo...@gmail.com>.
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 <se...@gmail.com> wrote:
>
> On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki <su...@google.com.invalid> 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 <jo...@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 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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> > --
> > Regards,
> > Tomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by sebb <se...@gmail.com>.
On Mon, 1 Feb 2021 at 16:52, Tomo Suzuki <su...@google.com.invalid> 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 <jo...@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 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> --
> Regards,
> Tomo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Introduce @NonNull, and @Nullable
Posted by Tomo Suzuki <su...@google.com.INVALID>.
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 <jo...@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 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Regards,
Tomo