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
