I started with a prototype of this and annotated a single package, so we could see what this would look like. Changes with commentary available at https://github.com/apache/poi/pull/203
On 2020/12/05 12:33:19, Marius Volkhart <mar...@volkhart.com> wrote: > Yes, I do not think this should hold up a release. It has no ABI implications and only has API implications for users of languages or tools that analyze/enforce nullness, and those users are typically prepared for such breakage when they opt-in to the checking. So I think the ramifications of such a change in a future minor release are likely to be acceptable. > > On 2020/12/02 23:21:43, "fannin...@apache.org" <fannin...@apache.org> wrote: > > Thanks Marius for bringing up this topic. > > > > POI is quite an old code base and I think it is safe to assume that virtually any return type can be null and that inputs can often be null too. > > > > If we start annotating the code, we would probably need to cover as many methods as possible because it would be confusing to have the annotations in some places but not in others. > > > > There is a discussion about doing a 5.0.0 release because it is a while since we did any releases. I'd prefer not to delay a release for this. We could certainly consider it after the next release. > > > > > > > > > > > > On Wednesday 2 December 2020, 22:37:46 GMT, Marius Volkhart < mar...@volkhart.com> wrote: > > > > > > > > > > > > Hello, > > > > As I've been working more with POI, I frequently find myself looking at the > > javadoc and source for whether or not a function can return null. I wanted > > to ask, would a contribution adding nullability annotations be welcomed? > > > > The basic idea is to annotate return values and method parameters with > > something like @Nullable and @NonNull. IDEs, static analysis tools, etc can > > then recognize these annotations and provide hints or analysis to the > > developer. For users of languages like Kotlin, that have stronger concepts > > of nullability, this is particularly helpful. > > > > The first consideration would be which annotations to use. A lot has been > > written on this. The JSR-305 FindBugs annotations come with licensing and > > legal concerns <https://github.com/google/guava/issues/2960> for example. > > However, projects like Spring Framework > > <https://github.com/spring-projects/spring-framework/issues/20099> have > > found ways around this. If indeed this contribution is of interest, I can > > go into more details on annotation selection and all that. > > > > The next consideration is how to do this without 1. making the POI codebase > > a mess, and 2. without making the task so monumental that one cannot > > complete it. Again, if the contribution is of interest, I can go into more > > details of a plan for anyone interested. > > > > -- > > Cheers, > > Marius Volkhart > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
