You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Marius Volkhart <Ma...@volkhart.com> on 2020/12/02 22:36:32 UTC
Nullability annotations
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
Re: Nullability annotations
Posted by Marius Volkhart <Ma...@volkhart.com>.
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, "fanningpj@apache.org" <fa...@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 <ma...@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-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org
Re: Nullability annotations
Posted by "fanningpj@apache.org" <fa...@apache.org>.
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 <ma...@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-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org