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. :-)
