Let’s go back to this post.  

Assume we figured out how to get rid of all the stuff you consider to be not 
required to be in the API. Even if we did that it still would not work in 
Android so long as the API contains module-info.java, because that class can 
only be compiled for Java 9.  So there really is no way to provide decent 
support for Java 9 and android at the same time. 

According to Gary’s findings, even if HttpClient switches to SLF4J they are 
going to be in the same boat with the 1.8.x releases.

Ralph

> On Dec 2, 2017, at 4:09 AM, 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.
> 


Reply via email to