If this is a runtime dependency then I am against using it in Log4J api and core.
Ralph > On Jan 2, 2024, at 3:17 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi all, > > Matt made an interesting proposal to use JSpecify nullability > annotations in Log4j: > > https://github.com/apache/logging-parent/issues/88 > > I am a big fan of nullability annotations but in my professional > experience they are worthless, unless the whole team agrees to use > them and how to introduce them. > > IMHO we should: > > * create a branch that will differ from `main` only for the present > of nullability annotations, > * depend directly (scope `provided`) on JSpecify, although this might > cause issue reports like this one [1], > * only merge the changes of one module at a time (starting with `log4j-api`), > * start by marking all fields and return types as `@Nullable` and all > parameters as `@NonNull`, > * only merge the change if a tool (NullAway/Checker Framework) > guarantees that the code is NPE-free. > * target 3.1.x as the first release with nullability annotations. > > What do you think? > > Piotr > > [1] https://github.com/apache/logging-log4j2/issues/2144
