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

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

Reply via email to