On Sun, Jul 9, 2017 at 1:29 PM, Matt Sicker <[email protected]> wrote:
> 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. > I am not advocating for an Android jar unless it is support things like, for example, logging to internal storage through the location provided by https://developer.android.com/reference/android/content/Context.html#getFilesDir() My hope is that: - log4j-api can be used as in on Android, it should be with out the Java 9 optimization in there. - A log4j-api-java9 jar can be provided with the Java 9 optimization - Eventually, we can split up log4j-core - Eventually, we can provide a log4j-android that contains either a bridge to Android logging or that contains an Android Appender that uses the various kinds of storage (internal vs. external) storage mechanisms. Gary > > 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]> >
