Hi, I'd like to point out, that there actually *is* a licensing issue regarding @NonNull and its siblings in javax.annotations : Not with the library, but with the prefix 'javax.'. As you might have noted, Oracle recently closed a deal with the Eclipse Foundation, allowing the Eclipse Foundation to step into the development of the JEE-API, under one essential premise: They have to drop the prefix 'javax.' and Eclipse is going to switch to the prefix 'jakarta.' instead.
Even if 'javax.annotation' & JSR-305 might not be considered part of deal this makes one thing pretty obvious: Oracle is not going to allow anybody else to add extend something into any of the 'javax.' packages. And since JSR-305 has been without development since 2012, officially declared 'dormant', it is rather unlikely, this will be taken up again now. So unless apache-commons is comfortable riding a dead horse, we shouldn't pull this into any commons module. This leaves us with 2 options: - Wait for somebody else to step in. Maybe the good folks at Eclipse Foundation are interested in taking that up too? They would be certainly free to duplicate the JSR-305 annotations into the jakarta Namespace. - Or rolling our own. I would be in favor of the second option, as this would be easier to control for commons. Maybe it is finally time to start modules 'annotation' and/or 'annotation-processing' within the commons-sandbox? Thomas On 01.02.2021 11:58, Jochen Wiedmann 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.) > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
