FWIW, it would make sense to me to make a log4j-core-android that is a subset of what is in core, if that is possible. Of course, the API problem has to be solved first.
Ralph > On Dec 2, 2017, at 9:38 AM, Ralph Goers <[email protected]> wrote: > > 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. >>>> >>> >
