I should point out that a lot of the crappy things we did with interfaces prior to Java 8 can now be undone. Some of it already has been. For example, ExtendedLogger was added so we could add new methods to the Logger interface. Those can now all be moved to the Logger interface as default methods. But ExtendedLogger still needs to stick around even if it is an empty interface as a lot of code references it. I already did that for LifeCycle2, MessageFactory2, AbstractMessageFactory and possibly others.
Ralph > On Dec 16, 2019, at 1:14 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >> On Dec 16, 2019, at 12:59 PM, Raman Gupta <rocketra...@gmail.com> wrote: >> >> What is the point of releasing log4j 3.x if you only intend to make >> non-breaking changes? Is it just a marketing thing then? > > We will be significantly impacting the implementation. We are breaking up > core into smaller modules. Until we upgraded 2.13.0 to Java 8 we had added > stuff to the API that couldn’t be implemented in Java 7. Since 2.13.0 is now > on Java 8 a lot of the new API stuff has been back ported, so I don’t expect > much difference there. > > The main driver for 3.0 was always to break it up so that core didn’t have so > many optional dependencies. That dove-tailed with JPMS in Java 9 so that most > of Log4j could be proper JPMS modules. > > I have also modified the plugin system to address problems that occur with > JPMS in finding them across modules - the plugin system no longer has a > Log4jPlugins.dat file. Instead it generates a class file containing the > plugin definitions which is loaded by the ServiceLoader. > > So 3.0 really will be a significant change. But it should still support > anything that was compiled against 2.x. > > Ralph > > > >
