It does seem that the problem is indeed only with log4j-api. While an Android developer might have some setup to get logging working during development, that's a separate scenario from simply allowing libraries that depend on log4j-api to still work in Android.
I do think that log4j-core could be useful on Android, but it'd really only be useful during development and not for end users. On 9 July 2017 at 11:35, Mikael Ståldal <[email protected]> wrote: > Assume that I am an Android developer. I don't know about Log4j, and I > don't care much about logging. I don't care about Java 9. > > In my Android app I want to use a Java library, which claims to support > Android. When I include a dependency to that library in my Gradle build, > the build breaks since the transitive dependency "log4j-api" has some Java > 9 classes in it. After mumbling about "damn this log4j crap", I try to > exclude it. Then I can build, but my app crash at runtime since the Java > library does some debug logging via Log4j API. > > To support Android means that the above does not happen. It means that the > build works and the app is not disrupted at runtime. It means that I can > live in bliss ignorance of Log4j. If all logging are just no-ops and > ignored on Android, that's OK for now. > > It is enough that log4j-api works on Android, log4j-core does not need to > work. I agree that most of log4j-core would be either impossible to get to > work, or not practically useful, on Android. > > > > On 2017-07-09 16:31, Apache wrote: > >> What does it mean to support android? You cannot log to a file system and >> many of our out of the box appender make no sense on a phone. >> >> What does having the API work on android mean without an implementation? >> We have never officially supported android and have just gotten our first >> Jura issue regarding it. >> >> I also keep hearing rumors that Google is going to drop Java in favor of >> a new language so I have suspicions they will never support Java 9. >> >> I don't want to go anywhere with android until I understand how it can >> be used. At that point I suspect we would create a jar that strips out >> stuff and call it Log4J-android. Dropping support for Java 9 should not be >> necessary to do that. >> >> Ralph >> >> On Jul 9, 2017, at 5:56 AM, Mikael Ståldal <[email protected]> wrote: >>> >>> No matter what we think about it, many other Java libraries want to be >>> compatible with Android (even though that's not the main target). Some of >>> them also do logging, today often with Log4j 1, SLF4J or commons-logging. >>> >>> If we want them to migrate to Log4j 2 API, then it is important that >>> log4j-api does not cause issues on Android. If log4j-api breaks on Android, >>> that may be the reason for those libraries to not use it. >>> >>> I guess that Apache http-components is an example of this. >>> >>> Android support in log4j-core is less important (we can defer that to >>> 2.10 or possibly not do it al all). We don't need to be able to do fancy >>> logging on Android, but log4j-api should at least not break the build or >>> disrupt the regular operation of the app at runtime. >>> >>> If we don't do anything about it, then your effort on LOG4J2-1926 might >>> be wasted when the Java 9 stuff breaks Android builds. >>> >>> >>> On 2017-07-09 14:15, Remko Popma wrote: >>>> Not sure I agree. Our interest in Android is a very recent thing. We've >>>> done some work with LOG4J2-1926 >>>> <https://issues.apache.org/jira/browse/LOG4J2-1926>, we are still >>>> discovering new work and I suspect we will keep discovering new issues >>>> as >>>> we start to take an in-depth look. If anything, let's make Android the >>>> "theme" for Log4j 2.10. >>>> Java 9 has been on the roadmap for a long time and is finally in a state >>>> where we can start asking for user feedback on it. >>>> I don't mind that Java 9 is still not officially released yet; it gives >>>> us >>>> some wiggle room in case we need to make changes. >>>> But I do like the version number symmetry: "Log4j offers Java 9 support >>>> from version 2.9". Call me a poet. :-) >>>> >>> >>> >> >> > -- Matt Sicker <[email protected]>
