Suppose we have an Android-specific api jar. Then when an Android developer gets log4j-api transitively, what now? I don't see normal libraries using log4j-api-android or something instead of the standard one.
On 9 July 2017 at 13:45, Gary Gregory <[email protected]> wrote: > On Sun, Jul 9, 2017 at 10:49 AM, Ralph Goers <[email protected]> > wrote: > > > When I investigated logging on android I came to the conclusion that the > > only usable logging that can be done in android is with the > implementation > > that Google provides. I have no problem creating a Log4J jar for android > > but I am not willing to not support Java 9 to do it. > > > > I am sorry but that feels a bit disingenuous to me. > > I have not heard anyone say we should not support Java 9, which ATM is just > an optimization, not something that is _required_ for Log4j to run on Java > 9. > > We support Java 9 already in 2.8.2: the code should runs when Java 9 comes > out if you use whatever unlocking command line options Java 9 provides WRT > modules, reflection, and who knows what other horrors of backwards > incompatibility Oracle has decided to put in there. Yes, kudos to Google > for adding Kotlin support. > > I've proposed we optimize for Java 9 it in a separate log4j-api-jar that an > Android developer would obviously not use; a jar for which we already have > a module. I am no Android expert, but I've not found a way to exclude the > Java 9 code from an Android build, maybe that's possible, who knows. > > A real life problem is when Log4j is brought in as a third party > dependency, then you're up the proverbial creek. > > Gary > > > > > > Ralph > > > > > On Jul 9, 2017, at 10:29 AM, Gary Gregory <[email protected]> > > wrote: > > > > > > But there is a file system on Android... > > > > > >> On Jul 9, 2017 10:15, "Matt Sicker" <[email protected]> wrote: > > >> > > >> 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]> > > >> > > > > > > > -- Matt Sicker <[email protected]>
