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
Sent: Friday, March 15, 2024 9:41 AM
To: Log4J Users List
Subject: Re: Deprecation of Log4j Supplier in 2.x...why? 😪
Hi Jeff,
On Fri, 15 Mar 2024 at 02:43, 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 attenti