Hallo Piotr, Oh geez 😝 another set of Nullability annotations lol...
To explicitly answer your question I *personally* would probably prefer #2... it is relatively small and those who don't want the JAR could explicitly exclude it. Regarding compiler warnings... We have an old monolith large build - between Maven and Java there are already so many spammy messages in our build logs - new Java open/closed package warnings from the JDK module system, Javadoc, Checkstyle, and, and, and ... and then add in hundreds if not thousands of deprecation warnings from Log4j and the build logs really blow up. If I have a chance to take a chunk out of that by asking a dumb question, I will 😃 If building locally, excessive log messages (i.e. IntelliJ for me) feels like it really slows the build down. But way more annoying is the effect of the deprecations in the IDE. Suddenly every logging statement is highlighting yellow and it is hard to find the "real" problems when validating the source-file. I really don't want to downgrade us to an older version of Log4j 2.x to avoid this and miss out on future maintenance/fixes. I personally don't like using @Deprecated to convey "intent-to-remove" without a documented and *available* replacement for the deprecated code. @SuppressWarnings at this scale is not an option - since it will also suppress valid warnings .. and ultimately need to be verified and removed later ... forces a maintenance task on us later. And now for my uninformed opinion about the nullabilty-annotations... About nullability annotations. I am not up-to-date on the discussion - never even heard of JSpecify until you mentioned it. However, we also very recently just made a huge push to get from the 'javax' to the 'jakarta' package namespace and where possible I have really been pushing my colleagues to start using the Jakarta annotations/constraints. Plus, we are integrating Spring into our monolith for which we are also using Jakarta constraint annotation validation. So after a *lot* of effort, we finally have everything sort of aligned with Jakarta EE right now. In addition, we have also partially implemented byte-buddy plugins on some of our internal JARs to insert runtime validation of @NotNull / @Nonnull Jakarta constraints. The idea of yet another set of nullability annotations doesn't excite me. ☹ I checked out the JSpecify documentation and at first glance I am not sure what the big benefits are - and the idea of a @NullMarked and all the conditional meanings is one I cannot really imagine my team of old-school developers will use or even understand. Plus you still end up bringing in Jakarta for all the other constraint validations (@NotBlank, @Positive, etc.) and non-constraint annotations (@Nullable, @PostConstruct, @PreDestroy, etc.) and so much of the tooling already works with this (IDE, Spring, etc.). I watched a video about JSpecify from Kevin Bourrillion (about 3 months old) - it doesn't really seem finalized yet and he said "It is a reference implementation. Prepare for a bumpy ride. You definitely should *not* include it your toolchain for your actual build" (paraphrasing). Plus he said that most tooling will not yet recognize the annotations. (https://www.youtube.com/watch?v=HS_kA42YNkU / 17:00 minutes in). He did argue at the beginning of the video that the 'javax.annotation' package is dormant for 11 years - while that might be true, it looks like the Jakarta annotation-api specification / JSR-175 is alive and well. (https://jakarta.ee/specifications/annotations/2.0/annotations-spec-2.0.html#specification-scope). Since we work with a lot of third-party libraries and some of them are older - I am not sure how to feel about the decisions to exclude the annotations on method parameters and possibly not on method scope. A lot of those 3rd-Party APIs (i.e Apache Axis2) don't specify nullability or even document the null-behavior. We have been using the Nullability annotations to wrap calls to these APIs on field parameters to specifically "document" what the behavior is. I personally like the explicitness of seeing the @Nullable/@NotNull annotations on each field - even if it might feel "bulky". I often find myself drilling through 20-layers of third-party API just to figure out what the heck it is going to do with a null argument (yes even log4j 😝). Cheers, Jeff -----Original Message----- From: Piotr P. Karwasz <piotr.karw...@gmail.com> Sent: Friday, March 15, 2024 9:41 AM To: Log4J Users List <log4j-user@logging.apache.org> Subject: Re: Deprecation of Log4j Supplier in 2.x...why? 😪 Hi Jeff, On Fri, 15 Mar 2024 at 02:43, <jeffrey.tho...@t-systems.com> 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/ --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
