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/