On Mon, 1 Feb 2021 at 22:39, Gary Gregory <garydgreg...@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 <seb...@gmail.com> wrote: > > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
