On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma <[email protected]> wrote:
> The log4j-api module could benefit from a util.internal package where we > move the util classes that are private and should not be exported. > Potentially an idea for a 3.0 release. > > (Shameless plug) Every java main() method deserves http://picocli.info Speaking of Picoli: It imports java.sql, which it should not for core to depend only on java.base. How should we deal with that? Gary > > > > On Jan 30, 2018, at 2:41, Remko Popma <[email protected]> wrote: > > > > If we want to do a 2.11 release that is binary compatible, I believe > that commit 21bc3aa is the last commit to include. > > From the following commit (ba658a0) we start to move classes and rename > packages - this would better fit in a 3.0 release where users would expect > some breaking changes in core. > > > >> On Tue, Jan 30, 2018 at 2:37 AM, Matt Sicker <[email protected]> wrote: > >> An SPI for log4j-core is one thing (also plugin factory cleanup). I'd > like > >> to see an improved plugin cache file that doesn't require a special > plugin > >> to merge them together when shading jars (would be better to just be > cat'd > >> together like a META-INF/services/ file). Removal of deprecated APIs > would > >> also be great. > >> > >> A 3.0 release also provides the ability to break APIs entirely if there > are > >> any awkward design decisions we found while incorporating GC-free > logging > >> and other nifty performance improvements. Utilising Java 8, we also have > >> the ability to support fully non-blocking asynchronous APIs using > >> CompleteableFuture which is rather interesting to me as well > (particularly > >> for networked appenders that provide async or reactive clients). > >> > >> As for bumping the version to 3.0 based on modules we already have, I > >> thought the main version was tied specifically to log4j-api. > >> > >> On 29 January 2018 at 11:28, Gary Gregory <[email protected]> > wrote: > >> > >> > On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory < > [email protected]> > >> > wrote: > >> > > >> > > On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker <[email protected]> > wrote: > >> > > > >> > >> I'd be +1 for Java 8, but making a 3.0 release is a different > story. For > >> > >> that, I'd like to see a lot more than just the Java version > increase. > >> > >> > >> > > > >> > > I think that a 3.0 would mark: > >> > > - A major change: Java 7 to Java 8 > >> > > - The internal clean up (in progress) with all the new modules > >> > > - Others stuff like maybe an SPI. > >> > > > >> > > >> > I would be happy to see an SPI for a 3.1.0 so we can take more time > with > >> > it. > >> > > >> > Gary > >> > > >> > > >> > > > >> > > Pushed back to 4.0 would be: > >> > > - Remove deprecated classes and methods > >> > > - Other stuff? > >> > > > >> > > Gary > >> > > > >> > > > >> > >> On 29 January 2018 at 11:07, Gary Gregory <[email protected]> > >> > wrote: > >> > >> > >> > >> > +1 to Java 8 now and call the next release 3.0. > >> > >> > > >> > >> > Gary > >> > >> > > >> > >> > On Mon, Jan 29, 2018 at 10:03 AM, Ralph Goers < > >> > >> [email protected]> > >> > >> > wrote: > >> > >> > > >> > >> > > Ceki has started a poll to upgrade Logback to Java 8 - > >> > >> > > https://doodle.com/poll/s7n3wk59694pmnbs < > https://doodle.com/poll/ > >> > >> > > s7n3wk59694pmnbs>. The last poll I saw was in May of last > year that > >> > >> had > >> > >> > > Java 7 at about 30%. https://plumbr.io/blog/java/ > >> > >> > > java-version-and-vendor-data-analyzed-2017-edition < > >> > >> > > https://plumbr.io/blog/java/java-version-and-vendor-data- > >> > >> > > analyzed-2017-edition>. Based on the Java 6 graph I anticipate > that > >> > >> Java > >> > >> > > 7 will be under 20% this year. I had been thinking that > upgrading to > >> > >> > Java 8 > >> > >> > > in September or so would be the right time, but with all this > >> > >> > > modularization work I am wondering if moving to Java 8 now > makes > >> > more > >> > >> > sense. > >> > >> > > > >> > >> > > Thoughts? > >> > >> > > > >> > >> > > Ralph > >> > >> > > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> Matt Sicker <[email protected]> > >> > >> > >> > > > >> > > > >> > > >> > >> > >> > >> -- > >> Matt Sicker <[email protected]> > > >
