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

Reply via email to