I see several issues:
StackLocator:
This cannot be removed from the API is the API as
LogManager.getLogger() calls it. Converting the Java 9 version to use
Reflection would add enough overhead that it probably wouldn’t be worth it to
use it. Also, you would have to figure out how to code the lambda expressions
without using Lambdas. Adding a log4j-java9 jar for api and/or core would
probably make us as unpopular with folks migrating to Java 9 as the current
situation is for Android users, but it may be the only viable solution.
Figuring out how to have the class files be ignored by Android seems reasonable
but nothing immediately comes to mind as to how to do it.
I made a log4j-android branch a while back that operates pretty much as Remko
describes below. It does not include the Java 9 support and includes a binding
to the android logger. However, I got an immediate complaint from an Android
user that they were not happy with that as they wanted access to core. It is
also a problem to have lots of pom files refer to log4j-api and to have to
exclude that and replace it with log4j-android instead.
I do not want to drop support for Java 9 but we do need to find a creative
solution for StackLocator. The limitations I am aware of with this are that
having multi-release jars and/or Java 9 classes in the jar cause problems with
tools. Also, having Java 9 source directly in log4j-api or log4j-core does not
play nice with IDEs.
The only thing that comes to mind with regarding having classes with a
different file extension would be to have a custom class loader that wraps
whatever the class loader is. Going down that road seems like it could be full
of problems.
Ralph
> On Dec 2, 2017, at 7:34 AM, Remko Popma <[email protected]> wrote:
>
> 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.
>>>
>>
