JNA does the same kind of magic to extract DLLs IIRC but that is for the lib path, not the classpath.
Gary On Sat, Dec 2, 2017 at 5:01 PM, Remko Popma <[email protected]> wrote: > 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. > > >>>> > > >>> > > > > > > > > >
