On Sun, Dec 15, 2019 at 5:56 PM Ralph Goers <[email protected]> wrote:
> > > > On Dec 15, 2019, at 2:44 PM, Gary Gregory <[email protected]> > wrote: > > > > All good thoughts. > > > > I suspect that now that 2.x is on Java 8 there are some clean ups we will > > want to do. What comes to mind immediately is deprecating our functional > > interfaces in favor of the ones in java.util.function. Then we can drop > our > > custom functional interfaces in the 3.0 branch (if that did not already > > happen.) > > Although I am not opposed, is there any benefit to that? It just adds more > binary incompatibilities. Although some are necessary I’d like to keep the > upgrade from 2.x to 3.0 as easy as possible. > By definition 3.0 is going to be binary incompatible with 2.x, so I am not worried about how much different it will be. Log4j 3 will have to be repackaged so that it can live in the same class loader as Log4j 2, otherwise, it will be a giant headache for people (like me) that live in large stacks with dependencies they cannot control that use all sorts of stuff. Gary > > > > > > At work, we are looking to move Java 11 as customers are uneasy running > on > > an EOL version like Java 8 (I know, I know, commercial support). As far > as > > making Java 11 the base requirement, we are somewhat waiting on IBM to > make > > Java 11 available on z/OS ( > https://developer.ibm.com/javasdk/support/zos/) > > > > So overall my thoughts are to make use of Java 8 in 2.x and seeing how > that > > allows 3.0 to be cleaned up. > > I don’t understand this statement. Are you agreeing that 3.0 should move > to Java 11 or just stating that you want 3.0 to be cleaned up? > > Ralph > > > > >
