Providing trimmed down .jar file is not so important for Android since
you always use ProGuard to remove unused classes when building an
Android app.
It is important to trim stuff that breaks on Android, but not to trim it
size-wise.
On 2017-07-10 23:40, Matt Sicker 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.
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
