Ok, you have some fair points there. Main take-away for me is that if we want Log4j2's API to become ubiquitous it needs to be at least painless for everyone. Don't known about the "too much stuff" in log4j-api - bit vague and not actionable.
What can we do, concretely? log4j-api --------- 1) I've already replaced the explicit references to JMX classes in log4j-api with reflection for Android compatibility. (LOG4J2-2126 <https://issues.apache.org/jira/browse/LOG4J2-2126> was a regression, fixed now) 2) The tricky bit is StackLocator. Options I can think of: a) reflection; b) separate log4j-api-java9 jar; c) rename java 9 class files to other extension than .class and load at runtime when running in Java 9 d) other? 3) The PID stuff can be moved to core (would still need some solution like for above (2) to allow use in Android). log4j-core ---------- We don't really have a good Android story for core. One option we can offer is log4j-api-android, which is a drop-in replacement for log4j-core that logs to Android's adb, similar to what "android.util.Log.d" does. However, we've had feedback from users who want to use normal log4j-core file logging facilities on Android (LOG4J2-1921 <https://issues.apache.org/jira/browse/LOG4J2-1921>). Maybe we can do the same for log4j-core as for log4j-api: use reflection or even separate jars :-( to make log4j-core work in Android. On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <[email protected]> wrote: > I fully understand Oleg's point of view. > > If we aim for Log4j 2's API to be the standard logging API/facade for > Java/JVM (eventually replacing SLF4J), then we have painted ourselves into > a corner by allowing log4j-api to grow out of bounds, and not paying enough > attention to the compatibility problems with Android (and possibly fringe > platforms) it causes. > > It is quite pointless to blame this on Android and its tooling. We can, > and should raise issues we find on Android tooling, and hope for them to > eventually get fixed. But that can take time, and at the end of the day > Android is what it is, and that's what users are going to use. If log4j-api > does not work on Android, most users will blame Log4j and not Android. > > And if a library with use cases both on standard Java and on Android, like > Apache HttpClient, have a required dependency on log4j-api and that causes > it to fail on Android, most users will blame HttpClient and not Android > (nor Log4j since they may be unaware of it). > > If I were maintainer of Apache HttpClient, I would also be very hesitant > to make it depend on log4j-api at this point. I don't think it is > constructive to just try to convince them given the current state of Log4j > and the Android tooling, we need to do some work on our end first (or > possibly volunteer to spend some effort on fixing the Android tooling). > > I think that the root cause is not Java 9 support, it is that we have > allowed too much stuff to go into log4j-api (instead of log4j-core), and > that started long before the Java 9 work. JMX is also incompatible with > Android, regardless of Java 9. > > With a thinner log4j-api, we could have added Java 9 support to log4j-core > only, and avoided this problem. > > > > On 2017-12-01 15:53, Gary Gregory wrote: > >> I had migrated HttpClient 5 to Log4j 2 but now there is push back due to >> the mess Java 9 has made of the META-INF folder and our adding support for >> Java 9 modules perhaps too soon. >> >> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and comment on >> that >> thread please. >> >
