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]> > >> > > >
