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.
