Nullability annotations are trivial to remove. I’ve added some basic aliases
for them in main. As it stands, they’re copies of the four JSpecify annotations
with those annotations applied to them along with equivalent JSR 305
meta-annotations to make the annotations function the same in
On Tue, Jan 2, 2024 at 1:00 PM Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Tue, 2 Jan 2024 at 11:59, Apache wrote:
> >
> > If this is a runtime dependency then I am against using it in Log4J api and
> > core.
>
> It is an annotation-only library, with a retention of `RUNTIME`.
> However annotat
Hi Ralph,
On Tue, 2 Jan 2024 at 11:59, Apache wrote:
>
> If this is a runtime dependency then I am against using it in Log4J api and
> core.
It is an annotation-only library, with a retention of `RUNTIME`.
However annotations should not cause `NoClassDefFoundError`s.
Piotr
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 wrote:
>
> Hi all,
>
> Matt made an interesting proposal to use JSpecify nullability
> annotations in Log4j:
>
> https://github.c
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