On Jul 10, 2017 14:40, "Matt Sicker" <[email protected]> wrote:
1. The stack is walked every time the LoggerContext has to be determined dynamically. This would be a really shitty tradeoff to remove. 2. I personally care more about supporting standard Java than Google's bastardization, so I'm more in support of the replaceable jar. It also provides a way to give a trimmed down version of log4j much more easily for Android use considering I doubt any Android apps are logging to a database for example. We have a nosql module, we should move the sql stuff to a new module... Gary On 10 July 2017 at 16:06, Ralph Goers <[email protected]> wrote: > I would also like to reiterate that StackWalker has to stay for Java 9. > The last time I benchmarked walking the stack in Java 9 was slower than in > Java 8 when not using StackWalker. See https://github.com/rgoers/ > stack-walker-benchmark <https://github.com/rgoers/stack-walker-benchmark>. > > Ralph > > > > On Jul 10, 2017, at 1:51 PM, Ralph Goers <[email protected]> > wrote: > > > > > >> On Jul 10, 2017, at 1:31 PM, Gary Gregory <[email protected]> > wrote: > >> > >> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the > only > >> difference with log4j-api be that the Java 9 optimization be absent? If > so, > >> that's a LOT of code duplication for no gain IMO. The KISS solution is a > >> log4j-api-java9 jar with the Java 9-specific code, right now, just the > one > >> class. > > > > I would suggest you look at log4j-api-android on the android branch. It > should provide a working implementation of the API on Android. > > > > The answer to your question is, “No”. It routes the Log4j API to the > android logger, which IMO is the ONLY sensible thing you can do on Android. > > > > Ralph > > -- Matt Sicker <[email protected]>
