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