On Sun, May 24, 2020 at 6:02 PM Ralph Goers <[email protected]> wrote:
> We can drop it where it won’t break backward compatibility. > It will break compatibility since APIs now typed to org.apache.logging.log4j.util.Supplier will be changed to java.util.function.Supplier. Call sites will have change imports from one package to another. IMO, there should not be expectation of compatibility, since master is 3.0 and a major version change. Depending on how far we go for 3.0, we should repackage to a log4j3 package so that a complex stack could have Log4j 1, 2 and 3 live in the same class loader. Otherwise, we will be creating some jar hell. A first step in any of this is to do this initial step (org.apache.logging.log4j.util.Supplier -> java.util.function.Supplier) plus Volkan's suggestion. Then we we can see how much breakage we cause but there is no excuse for shipping duplicate code (org.apache.logging.log4j.util.Supplier) for what is in Java 8 (java.util.function.Supplier) for 3.0 IMO. Gary > > Ralph > > > On May 24, 2020, at 2:57 PM, Volkan Yazıcı <[email protected]> > wrote: > > > > May I second that with {Bi,Tri}Consumer classes as well? > > > > On Sun, May 24, 2020 at 11:21 PM Gary Gregory <[email protected]> > wrote: > >> > >> Hi All, > >> > >> Can we drop org.apache.logging.log4j.util.Supplier from master for 3.x > and > >> replace its usage with java.util.function.Supplier? > >> > >> Gary > > > > >
