Re: Deprecation of Log4j Supplier in 2.x...why? 😪

"Piotr P. Karwasz" <[email protected]> Fri, 15 Mar 2024 09:40:38 +0100
Newsgroups gmane.comp.jakarta.log4j.user
Message-ID <CAFmygFbYFe7=VABVw=XVk8e+fYWdC0L7ydKbiEYE9+gGRZhgMQ@mail.gmail.com>
Hi Jeff,

On Fri, 15 Mar 2024 at 02:43, <[email protected]> wrote:
> Our builds are now ***full*** of deprecation warnings.  The IDE shows deprecation highlighting everywhere. Also, CI builds i.e. with Sonar evaluate use of deprecated API as Code Smells and Quality Gates fail.  When SQ quality gates fail our downstream jobs don't trigger.

Since you are one of the few users that pays attention to compiler
warnings, may I ask you for an opinion?

We are considering annotating our code with JSpecify nullability
annotations[1], which has a big chance to become THE nullability
annotation standard (instead of the 15-th nullability annotation
standard). Which one of these options would you prefer:

* we add JSpecify as a `provided` dependency: Maven will not download
the dependency in projects using Log4j API, but users will get many
compiler warnings about missing annotations. These are just warnings:
missing annotations cause no problems at runtime. Of course a user can
get rid of the warnings by including JSpecify in its own dependencies,
* we add JSpecify as a `compile` dependency and force users to
download the (2 KiB) JAR file.

Piotr

[1] https://jspecify.dev/