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" <piotr.karw...@gmail.com> wrote: Hi Jeff, On Fri, 15 Mar 2024 at 02:43, <jeffrey.tho...@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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
