On second thought, without a custom class loader we’d first need to copy these classes into the classpath.
This may not always be possible and sounds like a bad idea anyway. So please ignore my previous email. On Sun, Dec 3, 2017 at 8:38 Remko Popma <[email protected]> wrote: > > > On Dec 3, 2017, at 1:38, 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. > > We may not need a custom class loader. Idea: > > The Java 9 classes would be in the log4j-api jar, just with a different > extension (so the legacy tooling won’t choke on the version 53 bytecode). > > We can extract those classes into a temp directly, rename them back to the > canonical extension, and use the same class loader that loaded the other > log4j-api classes to load the Java 9 classes from the temp directory. > > If this fails, we fall back to the Java 7-compatible implementation. > > > > > 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. > >>>> > >>> > > > > >
