You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Je...@t-systems.com on 2024/03/15 01:42:13 UTC
Deprecation of Log4j Supplier in 2.x...why? 😪
Hello Log4j Team,
One of the great new features of Log4j2 is the lambda lazy logging.
Since we migrated to Log4j2 we have liberally been trying to take advantage of this where we can.
In the last few releases though, in preparation for Log4j 3.x the Log4j Supplier has been deprecated without replacement.
I get why you did this, but ... "why?" did you do this? 😁
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.
I read Hibernate did something similar to indicate "intent" without replacement, but they ultimately ended up reverting that change.
Cheers, Jeff
Re: Deprecation of Log4j Supplier in 2.x...why? 😪
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Jeff,
On Fri, 15 Mar 2024 at 07:50, <Je...@t-systems.com> wrote:
> Yes the Javadoc did a fine job of explaining the reason for the change and I understood it, but there are so many side-effects from deprecating those APIs. My question was more of a "why do this in advance?" 😆
The deprecation was introduced as a requirement of semantic versioning:
"Before you completely remove the functionality in a new major
release there should be at least one minor release that contains the
deprecation so that users can smoothly transition to the new API."[1]
However in January this year (cf. [2]) we decided that we will not
release a Log4j API 3.x version in the foreseeable future. We will
only release a major version of our logging backend Log4j Core. I
guess this means we can remove the @Deprecated annotation. Personally
it bothers me too to introduce all those `@SuppressWarnings`
annotations.
> It took us unfortunately a long time to get to 2.x and I am pretty sure we won't be jumping on the 3.0 version at release, so the idea of dealing with those deprecations for another 1-2 years is sobering. 😪
While we chose the same Java baseline as Spring Boot 3.x (Java 17),
Log4j Core 3.x will be easier to deploy, since it will just require
the replacement of a runtime dependency.
Piotr
[1] https://semver.org/#how-should-i-handle-deprecating-functionality
[2] https://lists.apache.org/thread/p2lgr3xtt9hq77j7r67r8x1tc1z7kbol
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Deprecation of Log4j Supplier in 2.x...why? 😪
Posted by Je...@t-systems.com.
Hey Piotr,
Thanks for the quick response.
Yes the Javadoc did a fine job of explaining the reason for the change and I understood it, but there are so many side-effects from deprecating those APIs. My question was more of a "why do this in advance?" 😆
And, in this case, even when switching to the JRE Supplier, it is a no code change (on "my" side) I think since the two interfaces are quasi identical... and a drop-in replacement which makes the deprecation more frustrating.
It took us unfortunately a long time to get to 2.x and I am pretty sure we won't be jumping on the 3.0 version at release, so the idea of dealing with those deprecations for another 1-2 years is sobering. 😪
Cheers, Jeff
sent with Corporate Mobile Service
On Mar 15, 2024 7:29 AM, "Piotr P. Karwasz" <pi...@gmail.com> wrote:
Hi Jeff,
On Fri, 15 Mar 2024 at 02:43, <Je...@t-systems.com> wrote:
> One of the great new features of Log4j2 is the lambda lazy logging.
>
> Since we migrated to Log4j2 we have liberally been trying to take advantage of this where we can.
>
> In the last few releases though, in preparation for Log4j 3.x the Log4j Supplier has been deprecated without replacement.
Sorry, if we were not specific enough in the Javadoc[1]. We would like
to replace `org.apache.logging.log4j.util.Supplier` with
`java.util.function.Supplier`, which is a source compatible change:
the compiler will just convert lambdas to another interface.
However this is more of a very long-term plan, which would probably
require an entirely new package name and `Logger` interface.
Effectively we should remove the `@Deprecated` annotation from our
code and just keep the Javadoc description.
Piotr
[1] https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/util/Supplier.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Deprecation of Log4j Supplier in 2.x...why? 😪
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Jeff,
On Fri, 15 Mar 2024 at 02:43, <Je...@t-systems.com> wrote:
> One of the great new features of Log4j2 is the lambda lazy logging.
>
> Since we migrated to Log4j2 we have liberally been trying to take advantage of this where we can.
>
> In the last few releases though, in preparation for Log4j 3.x the Log4j Supplier has been deprecated without replacement.
Sorry, if we were not specific enough in the Javadoc[1]. We would like
to replace `org.apache.logging.log4j.util.Supplier` with
`java.util.function.Supplier`, which is a source compatible change:
the compiler will just convert lambdas to another interface.
However this is more of a very long-term plan, which would probably
require an entirely new package name and `Logger` interface.
Effectively we should remove the `@Deprecated` annotation from our
code and just keep the Javadoc description.
Piotr
[1] https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/util/Supplier.html
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: Deprecation of Log4j Supplier in 2.x...why? 😪
Posted by Je...@t-systems.com.
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 <pi...@gmail.com>
Sent: Friday, March 15, 2024 9:41 AM
To: Log4J Users List <lo...@logging.apache.org>
Subject: Re: Deprecation of Log4j Supplier in 2.x...why? 😪
Hi Jeff,
On Fri, 15 Mar 2024 at 02:43, <Je...@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Deprecation of Log4j Supplier in 2.x...why? 😪
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Jeff,
On Fri, 15 Mar 2024 at 02:43, <Je...@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org