Ralph,
On 12/05/2022 17:17, Ralph Goers wrote:
Thanks,
We were just discussing this in our video call last week. It was also pointed
out that there are advantages to Log4j using its own Supplier although I cannot
remember what they were.
Of course, the Log4j Supplier could be modified to extend j.u.f.Supplier,
although I don’t know what the point of that would be.
Right. In terms of compatibility, I do not see any benefit from
extending j.u.f.Supplier.
Adding new methods that use j.u.f.Supplier almost certainly would just create a
mess and require casting all over the place.
Agreed. Such methods will always confuse type inference and lead to red
squiggly lines in the IDE :-( Not to mention the fact that there is
already a single-arg Object accepting variant, e.g. info(Object).
Yet another alternative, would be to not overload these methods further
but to add differently named ones, or to move into a new log4j3 package,
etc. But these have their own trade-offs.
My motivation for bringing this up now is just to explicitly highlight
the consequences and potential wide impact of such a change, not to make
any concrete suggestions. It's a difficult balancing act to weigh
compatibility against making progress, but ultimately j.u.f.Supplier is
the right choice (there are just different ways to get there).
-Chris.
