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
