You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Mikael Ståldal <mi...@apache.org> on 2017/07/09 11:13:48 UTC
[Log4j] 2.9 release and Java 9
As far as I understand, Java 9 will be released September 21.
Now we plan to release Log4j 2.9 before the end of July.
Given the problems that Java 9 causes, at least for Android, I suggest
that we de-scope the Java 9 specific stuff (StackLocator) from the 2.9
release.
It should be possible to do a 2.10 release with the Java 9 specific
stuff before September 21, right? And if not, that's not a disaster
since the 2.9 release will still work with Java 9 (just with non-optimal
performance for locationInfo), right?
I would say it's more important that log4j-api works on Android than we
get optimal performance for locationInfo on Java 9. Especially now when
Java 9 is not even officially released.
Re: [Log4j] 2.9 release and Java 9
Posted by Remko Popma <re...@gmail.com>.
* When I said "Java 9 has been on the roadmap" I meant the Log4j 2 roadmap.
On Sun, Jul 9, 2017 at 9:15 PM, Remko Popma <re...@gmail.com> 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. :-)
>
>
>
> On Sun, Jul 9, 2017 at 8:13 PM, Mikael Ståldal <mi...@apache.org> wrote:
>
>> As far as I understand, Java 9 will be released September 21.
>>
>> Now we plan to release Log4j 2.9 before the end of July.
>>
>> Given the problems that Java 9 causes, at least for Android, I suggest
>> that we de-scope the Java 9 specific stuff (StackLocator) from the 2.9
>> release.
>>
>> It should be possible to do a 2.10 release with the Java 9 specific stuff
>> before September 21, right? And if not, that's not a disaster since the 2.9
>> release will still work with Java 9 (just with non-optimal performance for
>> locationInfo), right?
>>
>> I would say it's more important that log4j-api works on Android than we
>> get optimal performance for locationInfo on Java 9. Especially now when
>> Java 9 is not even officially released.
>>
>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
It could be a classifier if it was in the log4j-api module, but I created a new module.
Ralph
> On Jul 9, 2017, at 10:28 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> On 9 July 2017 at 18:32, Ralph Goers <ra...@dslextreme.com> wrote:
>
>>
>>
>>> On Jul 9, 2017, at 1:29 PM, Matt Sicker <bo...@gmail.com> 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.
>>
>> This would be an android specific build, so they can exclude log4j-api and
>> include log4j-api-android instead. That isn’t much different than what
>> people have to do to use SLF4J’s commons-logging bridge.
>>
>> Ralph
>>
>
> That makes sense to me. Would it be appropriate to give this a classifier
> or just name it log4j-api-android? I'd imagine a classifier version might
> work if that is generated straight from log4j-api without the jdk9 classes
> added.
>
> --
> Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Apache <ra...@dslextreme.com>.
As I said before, that can be handled by a dependency swap.
Ralph
> On Jul 10, 2017, at 5:33 AM, Remko Popma <re...@gmail.com> wrote:
>
> One problem with the log4j-api-android idea is that it doesn't cover other
> libraries that bring in a dependency to log4j-api.
>
> However, I wouldn't mind saying Log4j 2.9 supports Java 9 but not Android;
> on Android use Log4j 2.8.
>
>
> (Shameless plug) Every java main() method deserves http://picocli.info
> FORK ME!!
>
>
>>> On Jul 10, 2017, at 14:28, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> On 9 July 2017 at 18:32, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>>
>>>
>>>> On Jul 9, 2017, at 1:29 PM, Matt Sicker <bo...@gmail.com> 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.
>>>
>>> This would be an android specific build, so they can exclude log4j-api
> and
>>> include log4j-api-android instead. That isn’t much different than what
>>> people have to do to use SLF4J’s commons-logging bridge.
>>>
>>> Ralph
>>>
>>
>> That makes sense to me. Would it be appropriate to give this a classifier
>> or just name it log4j-api-android? I'd imagine a classifier version might
>> work if that is generated straight from log4j-api without the jdk9 classes
>> added.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Mikael Ståldal <mi...@apache.org>.
We cannot say "on Android use Log4j 2.8" due to the problems you fixed
in https://issues.apache.org/jira/browse/LOG4J2-1926
On 2017-07-10 14:33, Remko Popma wrote:
> However, I wouldn't mind saying Log4j 2.9 supports Java 9 but not Android;
> on Android use Log4j 2.8.
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
The META-INF directory is the only standardized directory in a jar file
that's not supposed to be interpreted as containing code. Sure, there are
other -INF directories that other tools make like OSGI-INF, BOOT-INF,
WEB-INF, etc. It seems like a logical place. I don't know why the Android
plugin scans -INF directories for code.
On 10 July 2017 at 16:58, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Jul 10, 2017 at 2:52 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
> >
> >
> > On Jul 10, 2017 14:40, "Matt Sicker" <bo...@gmail.com> wrote:
> >
> > 1. The stack is walked every time the LoggerContext has to be determined
> > dynamically. This would be a really shitty tradeoff to remove.
> > 2. I personally care more about supporting standard Java than Google's
> > bastardization, so I'm more in support of the replaceable jar. It also
> > provides a way to give a trimmed down version of log4j much more easily
> for
> > Android use considering I doubt any Android apps are logging to a
> database
> > for example.
> >
> >
> On the op-ed side of things, I see Oracle has having really messed things
> up with Java 9. I know backward compat is important (but not too much in
> this case) but what kind of hack is it to put class files in the MANIFEST
> folder. Gross. What that the only way to do multi-release jars?
>
> Gary
>
> >
> > We have a nosql module, we should move the sql stuff to a new module...
> >
> > Gary
> >
> >
> > On 10 July 2017 at 16:06, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > > I would also like to reiterate that StackWalker has to stay for Java 9.
> > > The last time I benchmarked walking the stack in Java 9 was slower than
> > in
> > > Java 8 when not using StackWalker. See https://github.com/rgoers/
> > > stack-walker-benchmark <https://github.com/rgoers/
> stack-walker-benchmark
> > >.
> > >
> > > Ralph
> > >
> > >
> > > > On Jul 10, 2017, at 1:51 PM, Ralph Goers <ralph.goers@dslextreme.com
> >
> > > wrote:
> > > >
> > > >
> > > >> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > >>
> > > >> A log4j-api-android jar is a terrible idea and confusing: Wouldn't
> the
> > > only
> > > >> difference with log4j-api be that the Java 9 optimization be absent?
> > If
> > > so,
> > > >> that's a LOT of code duplication for no gain IMO. The KISS solution
> > is a
> > > >> log4j-api-java9 jar with the Java 9-specific code, right now, just
> the
> > > one
> > > >> class.
> > > >
> > > > I would suggest you look at log4j-api-android on the android branch.
> It
> > > should provide a working implementation of the API on Android.
> > > >
> > > > The answer to your question is, “No”. It routes the Log4j API to the
> > > android logger, which IMO is the ONLY sensible thing you can do on
> > Android.
> > > >
> > > > Ralph
> > >
> > >
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
> >
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
Forgot to add the link: <https://www.osgi.org/about-us/members/>. Lots of
people involved.
On 10 July 2017 at 17:19, Matt Sicker <bo...@gmail.com> wrote:
> OSGi's biggest contributors are Adobe, Bosch, Deutsche Telekom, Huawei,
> IBM, Liferay, NTT, Oracle (surprisingly), Paremus, and Software AG, though
> OSGi is a consortium, so similar to Java, it has a ton of other companies
> and organizations involved in various components. OSGi has its roots in
> embedded Java software and has only really recently gained traction in
> server software (like within the past few years; OSGi is almost as old as
> Java).
>
> On 10 July 2017 at 17:05, Ralph Goers <ra...@dslextreme.com> wrote:
>
>>
>> > On Jul 10, 2017, at 2:58 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > On Mon, Jul 10, 2017 at 2:52 PM, Gary Gregory <ga...@gmail.com>
>> > wrote:
>> >
>> >>
>> >>
>> >> On Jul 10, 2017 14:40, "Matt Sicker" <bo...@gmail.com> wrote:
>> >>
>> >> 1. The stack is walked every time the LoggerContext has to be
>> determined
>> >> dynamically. This would be a really shitty tradeoff to remove.
>> >> 2. I personally care more about supporting standard Java than Google's
>> >> bastardization, so I'm more in support of the replaceable jar. It also
>> >> provides a way to give a trimmed down version of log4j much more
>> easily for
>> >> Android use considering I doubt any Android apps are logging to a
>> database
>> >> for example.
>> >>
>> >>
>> > On the op-ed side of things, I see Oracle has having really messed
>> things
>> > up with Java 9. I know backward compat is important (but not too much in
>> > this case) but what kind of hack is it to put class files in the
>> MANIFEST
>> > folder. Gross. What that the only way to do multi-release jars?
>> >
>>
>> They aren’t in the MANIFEST folder because there isn’t one. It is
>> underneath META-INF. I am sure they did it this way because NO existing
>> tools should be looking for classes there. Unbelievably, both OSGi and
>> Android do. I can’t figure out what this says about Google, Oracle and
>> whoever leads OSGi.
>>
>> I can’t say I agree with everything that has been done in Java. The fact
>> that module-info files have a .java extension and are compiled into .class
>> files seems ridiculous to me. But we are way beyond the point where we have
>> any influence to change things, if we ever did. So we have to live with it
>> and move on.
>>
>> Ralph
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
OSGi's biggest contributors are Adobe, Bosch, Deutsche Telekom, Huawei,
IBM, Liferay, NTT, Oracle (surprisingly), Paremus, and Software AG, though
OSGi is a consortium, so similar to Java, it has a ton of other companies
and organizations involved in various components. OSGi has its roots in
embedded Java software and has only really recently gained traction in
server software (like within the past few years; OSGi is almost as old as
Java).
On 10 July 2017 at 17:05, Ralph Goers <ra...@dslextreme.com> wrote:
>
> > On Jul 10, 2017, at 2:58 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Mon, Jul 10, 2017 at 2:52 PM, Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Jul 10, 2017 14:40, "Matt Sicker" <bo...@gmail.com> wrote:
> >>
> >> 1. The stack is walked every time the LoggerContext has to be determined
> >> dynamically. This would be a really shitty tradeoff to remove.
> >> 2. I personally care more about supporting standard Java than Google's
> >> bastardization, so I'm more in support of the replaceable jar. It also
> >> provides a way to give a trimmed down version of log4j much more easily
> for
> >> Android use considering I doubt any Android apps are logging to a
> database
> >> for example.
> >>
> >>
> > On the op-ed side of things, I see Oracle has having really messed things
> > up with Java 9. I know backward compat is important (but not too much in
> > this case) but what kind of hack is it to put class files in the MANIFEST
> > folder. Gross. What that the only way to do multi-release jars?
> >
>
> They aren’t in the MANIFEST folder because there isn’t one. It is
> underneath META-INF. I am sure they did it this way because NO existing
> tools should be looking for classes there. Unbelievably, both OSGi and
> Android do. I can’t figure out what this says about Google, Oracle and
> whoever leads OSGi.
>
> I can’t say I agree with everything that has been done in Java. The fact
> that module-info files have a .java extension and are compiled into .class
> files seems ridiculous to me. But we are way beyond the point where we have
> any influence to change things, if we ever did. So we have to live with it
> and move on.
>
> Ralph
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jul 10, 2017, at 2:58 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Jul 10, 2017 at 2:52 PM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>>
>>
>> On Jul 10, 2017 14:40, "Matt Sicker" <bo...@gmail.com> wrote:
>>
>> 1. The stack is walked every time the LoggerContext has to be determined
>> dynamically. This would be a really shitty tradeoff to remove.
>> 2. I personally care more about supporting standard Java than Google's
>> bastardization, so I'm more in support of the replaceable jar. It also
>> provides a way to give a trimmed down version of log4j much more easily for
>> Android use considering I doubt any Android apps are logging to a database
>> for example.
>>
>>
> On the op-ed side of things, I see Oracle has having really messed things
> up with Java 9. I know backward compat is important (but not too much in
> this case) but what kind of hack is it to put class files in the MANIFEST
> folder. Gross. What that the only way to do multi-release jars?
>
They aren’t in the MANIFEST folder because there isn’t one. It is underneath META-INF. I am sure they did it this way because NO existing tools should be looking for classes there. Unbelievably, both OSGi and Android do. I can’t figure out what this says about Google, Oracle and whoever leads OSGi.
I can’t say I agree with everything that has been done in Java. The fact that module-info files have a .java extension and are compiled into .class files seems ridiculous to me. But we are way beyond the point where we have any influence to change things, if we ever did. So we have to live with it and move on.
Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jul 10, 2017 at 2:52 PM, Gary Gregory <ga...@gmail.com>
wrote:
>
>
> On Jul 10, 2017 14:40, "Matt Sicker" <bo...@gmail.com> wrote:
>
> 1. The stack is walked every time the LoggerContext has to be determined
> dynamically. This would be a really shitty tradeoff to remove.
> 2. I personally care more about supporting standard Java than Google's
> bastardization, so I'm more in support of the replaceable jar. It also
> provides a way to give a trimmed down version of log4j much more easily for
> Android use considering I doubt any Android apps are logging to a database
> for example.
>
>
On the op-ed side of things, I see Oracle has having really messed things
up with Java 9. I know backward compat is important (but not too much in
this case) but what kind of hack is it to put class files in the MANIFEST
folder. Gross. What that the only way to do multi-release jars?
Gary
>
> We have a nosql module, we should move the sql stuff to a new module...
>
> Gary
>
>
> On 10 July 2017 at 16:06, Ralph Goers <ra...@dslextreme.com> wrote:
>
> > I would also like to reiterate that StackWalker has to stay for Java 9.
> > The last time I benchmarked walking the stack in Java 9 was slower than
> in
> > Java 8 when not using StackWalker. See https://github.com/rgoers/
> > stack-walker-benchmark <https://github.com/rgoers/stack-walker-benchmark
> >.
> >
> > Ralph
> >
> >
> > > On Jul 10, 2017, at 1:51 PM, Ralph Goers <ra...@dslextreme.com>
> > wrote:
> > >
> > >
> > >> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > >>
> > >> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the
> > only
> > >> difference with log4j-api be that the Java 9 optimization be absent?
> If
> > so,
> > >> that's a LOT of code duplication for no gain IMO. The KISS solution
> is a
> > >> log4j-api-java9 jar with the Java 9-specific code, right now, just the
> > one
> > >> class.
> > >
> > > I would suggest you look at log4j-api-android on the android branch. It
> > should provide a working implementation of the API on Android.
> > >
> > > The answer to your question is, “No”. It routes the Log4j API to the
> > android logger, which IMO is the ONLY sensible thing you can do on
> Android.
> > >
> > > Ralph
> >
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
That was just a random example. I can't imagine most of the core appenders
are useful in Android, and that includes the ones that use Java SE classes
only.
On 10 July 2017 at 16:52, Gary Gregory <ga...@gmail.com> wrote:
> On Jul 10, 2017 14:40, "Matt Sicker" <bo...@gmail.com> wrote:
>
> 1. The stack is walked every time the LoggerContext has to be determined
> dynamically. This would be a really shitty tradeoff to remove.
> 2. I personally care more about supporting standard Java than Google's
> bastardization, so I'm more in support of the replaceable jar. It also
> provides a way to give a trimmed down version of log4j much more easily for
> Android use considering I doubt any Android apps are logging to a database
> for example.
>
>
> We have a nosql module, we should move the sql stuff to a new module...
>
> Gary
>
>
> On 10 July 2017 at 16:06, Ralph Goers <ra...@dslextreme.com> wrote:
>
> > I would also like to reiterate that StackWalker has to stay for Java 9.
> > The last time I benchmarked walking the stack in Java 9 was slower than
> in
> > Java 8 when not using StackWalker. See https://github.com/rgoers/
> > stack-walker-benchmark <https://github.com/rgoers/stack-walker-benchmark
> >.
> >
> > Ralph
> >
> >
> > > On Jul 10, 2017, at 1:51 PM, Ralph Goers <ra...@dslextreme.com>
> > wrote:
> > >
> > >
> > >> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > >>
> > >> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the
> > only
> > >> difference with log4j-api be that the Java 9 optimization be absent?
> If
> > so,
> > >> that's a LOT of code duplication for no gain IMO. The KISS solution is
> a
> > >> log4j-api-java9 jar with the Java 9-specific code, right now, just the
> > one
> > >> class.
> > >
> > > I would suggest you look at log4j-api-android on the android branch. It
> > should provide a working implementation of the API on Android.
> > >
> > > The answer to your question is, “No”. It routes the Log4j API to the
> > android logger, which IMO is the ONLY sensible thing you can do on
> Android.
> > >
> > > Ralph
> >
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Gary Gregory <ga...@gmail.com>.
On Jul 10, 2017 14:40, "Matt Sicker" <bo...@gmail.com> wrote:
1. The stack is walked every time the LoggerContext has to be determined
dynamically. This would be a really shitty tradeoff to remove.
2. I personally care more about supporting standard Java than Google's
bastardization, so I'm more in support of the replaceable jar. It also
provides a way to give a trimmed down version of log4j much more easily for
Android use considering I doubt any Android apps are logging to a database
for example.
We have a nosql module, we should move the sql stuff to a new module...
Gary
On 10 July 2017 at 16:06, Ralph Goers <ra...@dslextreme.com> wrote:
> I would also like to reiterate that StackWalker has to stay for Java 9.
> The last time I benchmarked walking the stack in Java 9 was slower than in
> Java 8 when not using StackWalker. See https://github.com/rgoers/
> stack-walker-benchmark <https://github.com/rgoers/stack-walker-benchmark>.
>
> Ralph
>
>
> > On Jul 10, 2017, at 1:51 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> >
> >> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the
> only
> >> difference with log4j-api be that the Java 9 optimization be absent? If
> so,
> >> that's a LOT of code duplication for no gain IMO. The KISS solution is
a
> >> log4j-api-java9 jar with the Java 9-specific code, right now, just the
> one
> >> class.
> >
> > I would suggest you look at log4j-api-android on the android branch. It
> should provide a working implementation of the API on Android.
> >
> > The answer to your question is, “No”. It routes the Log4j API to the
> android logger, which IMO is the ONLY sensible thing you can do on
Android.
> >
> > Ralph
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Mikael Ståldal <mi...@apache.org>.
Providing trimmed down .jar file is not so important for Android since
you always use ProGuard to remove unused classes when building an
Android app.
It is important to trim stuff that breaks on Android, but not to trim it
size-wise.
On 2017-07-10 23:40, Matt Sicker wrote:
> 1. The stack is walked every time the LoggerContext has to be determined
> dynamically. This would be a really shitty tradeoff to remove.
> 2. I personally care more about supporting standard Java than Google's
> bastardization, so I'm more in support of the replaceable jar. It also
> provides a way to give a trimmed down version of log4j much more easily for
> Android use considering I doubt any Android apps are logging to a database
> for example.
>
> On 10 July 2017 at 16:06, Ralph Goers <ra...@dslextreme.com> wrote:
>
>> I would also like to reiterate that StackWalker has to stay for Java 9.
>> The last time I benchmarked walking the stack in Java 9 was slower than in
>> Java 8 when not using StackWalker. See https://github.com/rgoers/
>> stack-walker-benchmark <https://github.com/rgoers/stack-walker-benchmark>.
>>
>> Ralph
>>
>>
>>> On Jul 10, 2017, at 1:51 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>>
>>>
>>>> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>
>>>> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the
>> only
>>>> difference with log4j-api be that the Java 9 optimization be absent? If
>> so,
>>>> that's a LOT of code duplication for no gain IMO. The KISS solution is a
>>>> log4j-api-java9 jar with the Java 9-specific code, right now, just the
>> one
>>>> class.
>>>
>>> I would suggest you look at log4j-api-android on the android branch. It
>> should provide a working implementation of the API on Android.
>>>
>>> The answer to your question is, “No”. It routes the Log4j API to the
>> android logger, which IMO is the ONLY sensible thing you can do on Android.
>>>
>>> Ralph
>>
>>
>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
1. The stack is walked every time the LoggerContext has to be determined
dynamically. This would be a really shitty tradeoff to remove.
2. I personally care more about supporting standard Java than Google's
bastardization, so I'm more in support of the replaceable jar. It also
provides a way to give a trimmed down version of log4j much more easily for
Android use considering I doubt any Android apps are logging to a database
for example.
On 10 July 2017 at 16:06, Ralph Goers <ra...@dslextreme.com> wrote:
> I would also like to reiterate that StackWalker has to stay for Java 9.
> The last time I benchmarked walking the stack in Java 9 was slower than in
> Java 8 when not using StackWalker. See https://github.com/rgoers/
> stack-walker-benchmark <https://github.com/rgoers/stack-walker-benchmark>.
>
> Ralph
>
>
> > On Jul 10, 2017, at 1:51 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> >
> >> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the
> only
> >> difference with log4j-api be that the Java 9 optimization be absent? If
> so,
> >> that's a LOT of code duplication for no gain IMO. The KISS solution is a
> >> log4j-api-java9 jar with the Java 9-specific code, right now, just the
> one
> >> class.
> >
> > I would suggest you look at log4j-api-android on the android branch. It
> should provide a working implementation of the API on Android.
> >
> > The answer to your question is, “No”. It routes the Log4j API to the
> android logger, which IMO is the ONLY sensible thing you can do on Android.
> >
> > Ralph
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
I would also like to reiterate that StackWalker has to stay for Java 9. The last time I benchmarked walking the stack in Java 9 was slower than in Java 8 when not using StackWalker. See https://github.com/rgoers/stack-walker-benchmark <https://github.com/rgoers/stack-walker-benchmark>.
Ralph
> On Jul 10, 2017, at 1:51 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the only
>> difference with log4j-api be that the Java 9 optimization be absent? If so,
>> that's a LOT of code duplication for no gain IMO. The KISS solution is a
>> log4j-api-java9 jar with the Java 9-specific code, right now, just the one
>> class.
>
> I would suggest you look at log4j-api-android on the android branch. It should provide a working implementation of the API on Android.
>
> The answer to your question is, “No”. It routes the Log4j API to the android logger, which IMO is the ONLY sensible thing you can do on Android.
>
> Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jul 10, 2017, at 3:12 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Does the log4j-android module shade in log4j-api or something? If not, we
> still have the same exact initial problem of Java 9 classes being in the
> jar.
It specifically excludes the Java 9 class(es) under META-INF.
Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
Does the log4j-android module shade in log4j-api or something? If not, we
still have the same exact initial problem of Java 9 classes being in the
jar.
On 10 July 2017 at 17:08, Remko Popma <re...@gmail.com> wrote:
> I think both Gary and myself had the same misunderstanding about
> log4j-api-android. I didn't realize it contains a bridge/adapter to the
> Android logging implementation until you mentioned it.
>
> Would `log4j-api-android-impl` be a better name?
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Jul 11, 2017, at 5:51, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> >
> >> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the
> only
> >> difference with log4j-api be that the Java 9 optimization be absent? If
> so,
> >> that's a LOT of code duplication for no gain IMO. The KISS solution is a
> >> log4j-api-java9 jar with the Java 9-specific code, right now, just the
> one
> >> class.
> >
> > I would suggest you look at log4j-api-android on the android branch. It
> should provide a working implementation of the API on Android.
> >
> > The answer to your question is, “No”. It routes the Log4j API to the
> android logger, which IMO is the ONLY sensible thing you can do on Android.
> >
> > Ralph
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Remko Popma <re...@gmail.com>.
I think both Gary and myself had the same misunderstanding about log4j-api-android. I didn't realize it contains a bridge/adapter to the Android logging implementation until you mentioned it.
Would `log4j-api-android-impl` be a better name?
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jul 11, 2017, at 5:51, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the only
>> difference with log4j-api be that the Java 9 optimization be absent? If so,
>> that's a LOT of code duplication for no gain IMO. The KISS solution is a
>> log4j-api-java9 jar with the Java 9-specific code, right now, just the one
>> class.
>
> I would suggest you look at log4j-api-android on the android branch. It should provide a working implementation of the API on Android.
>
> The answer to your question is, “No”. It routes the Log4j API to the android logger, which IMO is the ONLY sensible thing you can do on Android.
>
> Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jul 10, 2017, at 1:31 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> A log4j-api-android jar is a terrible idea and confusing: Wouldn't the only
> difference with log4j-api be that the Java 9 optimization be absent? If so,
> that's a LOT of code duplication for no gain IMO. The KISS solution is a
> log4j-api-java9 jar with the Java 9-specific code, right now, just the one
> class.
I would suggest you look at log4j-api-android on the android branch. It should provide a working implementation of the API on Android.
The answer to your question is, “No”. It routes the Log4j API to the android logger, which IMO is the ONLY sensible thing you can do on Android.
Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Gary Gregory <ga...@gmail.com>.
A log4j-api-android jar is a terrible idea and confusing: Wouldn't the only
difference with log4j-api be that the Java 9 optimization be absent? If so,
that's a LOT of code duplication for no gain IMO. The KISS solution is a
log4j-api-java9 jar with the Java 9-specific code, right now, just the one
class.
Gary
On Mon, Jul 10, 2017 at 1:25 PM, Mikael Ståldal <mi...@apache.org> wrote:
> Exactly. It would be better with a log4j-api that works on Android and
> then a log4j-android module as an alternative to log4j-core.
>
>
>
> On 2017-07-10 14:33, Remko Popma wrote:
>
>> One problem with the log4j-api-android idea is that it doesn't cover other
>> libraries that bring in a dependency to log4j-api.
>>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
It's also possible that the Android build tools will be updated by the time
Java 9 is released (or sometime afterward) to fix this issue. The same goes
for the OSGi build tools.
On 12 July 2017 at 15:32, Ralph Goers <ra...@dslextreme.com> wrote:
> I should also stress again that I have not tested this so although it
> looks like it should work I make no guarantees until it can be tested.
>
> Ralph
>
> > On Jul 12, 2017, at 1:31 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > Yeah, it would be nice to tell Maven/Nexus to use a different artifact
> when building for Android but the best we can do is to document it well on
> the web site.
> >
> > Ralph
> >
> >> On Jul 12, 2017, at 12:49 PM, Mikael Ståldal <mi...@apache.org> wrote:
> >>
> >> It looks fine.
> >>
> >> The problem is that Android developers who get a transitive dependency
> to log4j-api now explicitly have to exclude it, and include
> log4j-api-android instead.
> >>
> >> It is not hard to do, but how do we reach out to those Android
> developers who might not even know what Log4j is (and don't care much about
> logging)?
> >>
> >>
> >> On 2017-07-10 22:49, Ralph Goers wrote:
> >>>> On Jul 10, 2017, at 1:48 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >>>>
> >>>>
> >>>>> On Jul 10, 2017, at 1:25 PM, Mikael Ståldal <mi...@apache.org>
> wrote:
> >>>>>
> >>>>> Exactly. It would be better with a log4j-api that works on Android
> and then a log4j-android module as an alternative to log4j-core.
> >>>>>
> >>>>
> >>>>
> >>>> I would suggest you look at log4j-api-android. It should provide a
> working implementation of the API on Android. I really don’t see the point
> of doing much more than this on a phone.
> >>> This is on the android branch.
> >>>>
> >>>> Ralph
> >>
> >>
> >
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
I should also stress again that I have not tested this so although it looks like it should work I make no guarantees until it can be tested.
Ralph
> On Jul 12, 2017, at 1:31 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Yeah, it would be nice to tell Maven/Nexus to use a different artifact when building for Android but the best we can do is to document it well on the web site.
>
> Ralph
>
>> On Jul 12, 2017, at 12:49 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>
>> It looks fine.
>>
>> The problem is that Android developers who get a transitive dependency to log4j-api now explicitly have to exclude it, and include log4j-api-android instead.
>>
>> It is not hard to do, but how do we reach out to those Android developers who might not even know what Log4j is (and don't care much about logging)?
>>
>>
>> On 2017-07-10 22:49, Ralph Goers wrote:
>>>> On Jul 10, 2017, at 1:48 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>
>>>>
>>>>> On Jul 10, 2017, at 1:25 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>>>>
>>>>> Exactly. It would be better with a log4j-api that works on Android and then a log4j-android module as an alternative to log4j-core.
>>>>>
>>>>
>>>>
>>>> I would suggest you look at log4j-api-android. It should provide a working implementation of the API on Android. I really don’t see the point of doing much more than this on a phone.
>>> This is on the android branch.
>>>>
>>>> Ralph
>>
>>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
Yeah, it would be nice to tell Maven/Nexus to use a different artifact when building for Android but the best we can do is to document it well on the web site.
Ralph
> On Jul 12, 2017, at 12:49 PM, Mikael Ståldal <mi...@apache.org> wrote:
>
> It looks fine.
>
> The problem is that Android developers who get a transitive dependency to log4j-api now explicitly have to exclude it, and include log4j-api-android instead.
>
> It is not hard to do, but how do we reach out to those Android developers who might not even know what Log4j is (and don't care much about logging)?
>
>
> On 2017-07-10 22:49, Ralph Goers wrote:
>>> On Jul 10, 2017, at 1:48 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>>
>>>> On Jul 10, 2017, at 1:25 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>>>
>>>> Exactly. It would be better with a log4j-api that works on Android and then a log4j-android module as an alternative to log4j-core.
>>>>
>>>
>>>
>>> I would suggest you look at log4j-api-android. It should provide a working implementation of the API on Android. I really don’t see the point of doing much more than this on a phone.
>> This is on the android branch.
>>>
>>> Ralph
>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Mikael Ståldal <mi...@apache.org>.
It looks fine.
The problem is that Android developers who get a transitive dependency
to log4j-api now explicitly have to exclude it, and include
log4j-api-android instead.
It is not hard to do, but how do we reach out to those Android
developers who might not even know what Log4j is (and don't care much
about logging)?
On 2017-07-10 22:49, Ralph Goers wrote:
>
>> On Jul 10, 2017, at 1:48 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>>
>>> On Jul 10, 2017, at 1:25 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>>
>>> Exactly. It would be better with a log4j-api that works on Android and then a log4j-android module as an alternative to log4j-core.
>>>
>>
>>
>> I would suggest you look at log4j-api-android. It should provide a working implementation of the API on Android. I really don’t see the point of doing much more than this on a phone.
>
> This is on the android branch.
>
>>
>> Ralph
>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jul 10, 2017, at 1:48 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>> On Jul 10, 2017, at 1:25 PM, Mikael Ståldal <mi...@apache.org> wrote:
>>
>> Exactly. It would be better with a log4j-api that works on Android and then a log4j-android module as an alternative to log4j-core.
>>
>
>
> I would suggest you look at log4j-api-android. It should provide a working implementation of the API on Android. I really don’t see the point of doing much more than this on a phone.
This is on the android branch.
>
> Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jul 10, 2017, at 1:25 PM, Mikael Ståldal <mi...@apache.org> wrote:
>
> Exactly. It would be better with a log4j-api that works on Android and then a log4j-android module as an alternative to log4j-core.
>
I would suggest you look at log4j-api-android. It should provide a working implementation of the API on Android. I really don’t see the point of doing much more than this on a phone.
Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Mikael Ståldal <mi...@apache.org>.
Exactly. It would be better with a log4j-api that works on Android and
then a log4j-android module as an alternative to log4j-core.
On 2017-07-10 14:33, Remko Popma wrote:
> One problem with the log4j-api-android idea is that it doesn't cover other
> libraries that bring in a dependency to log4j-api.
Re: [Log4j] 2.9 release and Java 9
Posted by Remko Popma <re...@gmail.com>.
One problem with the log4j-api-android idea is that it doesn't cover other
libraries that bring in a dependency to log4j-api.
However, I wouldn't mind saying Log4j 2.9 supports Java 9 but not Android;
on Android use Log4j 2.8.
(Shameless plug) Every java main() method deserves http://picocli.info
FORK ME!!
> On Jul 10, 2017, at 14:28, Matt Sicker <bo...@gmail.com> wrote:
>
>> On 9 July 2017 at 18:32, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>>
>>
>>> On Jul 9, 2017, at 1:29 PM, Matt Sicker <bo...@gmail.com> 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.
>>
>> This would be an android specific build, so they can exclude log4j-api
and
>> include log4j-api-android instead. That isn’t much different than what
>> people have to do to use SLF4J’s commons-logging bridge.
>>
>> Ralph
>>
>
> That makes sense to me. Would it be appropriate to give this a classifier
> or just name it log4j-api-android? I'd imagine a classifier version might
> work if that is generated straight from log4j-api without the jdk9 classes
> added.
>
> --
> Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
On 9 July 2017 at 18:32, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
> > On Jul 9, 2017, at 1:29 PM, Matt Sicker <bo...@gmail.com> 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.
>
> This would be an android specific build, so they can exclude log4j-api and
> include log4j-api-android instead. That isn’t much different than what
> people have to do to use SLF4J’s commons-logging bridge.
>
> Ralph
>
That makes sense to me. Would it be appropriate to give this a classifier
or just name it log4j-api-android? I'd imagine a classifier version might
work if that is generated straight from log4j-api without the jdk9 classes
added.
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jul 9, 2017, at 1:29 PM, Matt Sicker <bo...@gmail.com> 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.
This would be an android specific build, so they can exclude log4j-api and include log4j-api-android instead. That isn’t much different than what people have to do to use SLF4J’s commons-logging bridge.
Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
I created a log4j-api-android module on branch “android”. It contains an AndroidLogger that logs to android.util.Log. I have not built it on Android or tested it. Can you give it a whirl?
Ralph
> On Jul 9, 2017, at 5:11 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Jul 9, 2017 16:59, "Ralph Goers" <ra...@dslextreme.com> wrote:
>
>
>> On Jul 9, 2017, at 2:42 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Sun, Jul 9, 2017 at 1:29 PM, Matt Sicker <bo...@gmail.com> 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()
>>
>
> I would have no problem having an Android jar that contains the api and
> some android specific implementation.
>
>
> Great, but as of now, we cannot have that until current log4j-api jar is
> changed.
>
> Gary
>
>
> Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Gary Gregory <ga...@gmail.com>.
On Jul 9, 2017 16:59, "Ralph Goers" <ra...@dslextreme.com> wrote:
> On Jul 9, 2017, at 2:42 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sun, Jul 9, 2017 at 1:29 PM, Matt Sicker <bo...@gmail.com> 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()
>
I would have no problem having an Android jar that contains the api and
some android specific implementation.
Great, but as of now, we cannot have that until current log4j-api jar is
changed.
Gary
Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jul 9, 2017, at 2:42 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sun, Jul 9, 2017 at 1:29 PM, Matt Sicker <bo...@gmail.com> 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()
>
I would have no problem having an Android jar that contains the api and some android specific implementation.
Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Jul 9, 2017 at 1:29 PM, Matt Sicker <bo...@gmail.com> 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 <ga...@gmail.com> wrote:
>
> > On Sun, Jul 9, 2017 at 10:49 AM, Ralph Goers <ralph.goers@dslextreme.com
> >
> > 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 <ga...@gmail.com>
> > > wrote:
> > > >
> > > > But there is a file system on Android...
> > > >
> > > >> On Jul 9, 2017 10:15, "Matt Sicker" <bo...@gmail.com> 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 <mi...@apache.org> 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 <mi...@apache.org>
> > 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 <bo...@gmail.com>
> > > >>
> > >
> > >
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@gmail.com> wrote:
> On Sun, Jul 9, 2017 at 10:49 AM, Ralph Goers <ra...@dslextreme.com>
> 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 <ga...@gmail.com>
> > wrote:
> > >
> > > But there is a file system on Android...
> > >
> > >> On Jul 9, 2017 10:15, "Matt Sicker" <bo...@gmail.com> 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 <mi...@apache.org> 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 <mi...@apache.org>
> 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 <bo...@gmail.com>
> > >>
> >
> >
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jul 9, 2017, at 11:45 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sun, Jul 9, 2017 at 10:49 AM, Ralph Goers <ra...@dslextreme.com>
> 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.
Let me be blunt. I am -1 on removing the StackWalker code. I am quite sure that I could create a log4j-api-android jar that does not include Stackwalker. In fact, it would be trivial.
>
> A real life problem is when Log4j is brought in as a third party
> dependency, then you're up the proverbial creek.
>
> Gary
>
Ralph
Re: [Log4j] 2.9 release and Java 9
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Jul 9, 2017 at 10:49 AM, Ralph Goers <ra...@dslextreme.com>
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 <ga...@gmail.com>
> wrote:
> >
> > But there is a file system on Android...
> >
> >> On Jul 9, 2017 10:15, "Matt Sicker" <bo...@gmail.com> 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 <mi...@apache.org> 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 <mi...@apache.org> 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 <bo...@gmail.com>
> >>
>
>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Ralph Goers <ra...@dslextreme.com>.
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.
Ralph
> On Jul 9, 2017, at 10:29 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> But there is a file system on Android...
>
>> On Jul 9, 2017 10:15, "Matt Sicker" <bo...@gmail.com> 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 <mi...@apache.org> 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 <mi...@apache.org> 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 <bo...@gmail.com>
>>
Re: [Log4j] 2.9 release and Java 9
Posted by Gary Gregory <ga...@gmail.com>.
But there is a file system on Android...
On Jul 9, 2017 10:15, "Matt Sicker" <bo...@gmail.com> 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 <mi...@apache.org> 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 <mi...@apache.org> 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 <bo...@gmail.com>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Matt Sicker <bo...@gmail.com>.
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 <mi...@apache.org> 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 <mi...@apache.org> 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 <bo...@gmail.com>
Re: [Log4j] 2.9 release and Java 9
Posted by Mikael Ståldal <mi...@apache.org>.
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 <mi...@apache.org> 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. :-)
>>
>
>
Re: [Log4j] 2.9 release and Java 9
Posted by Apache <ra...@dslextreme.com>.
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 <mi...@apache.org> 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. :-)
>
Re: [Log4j] 2.9 release and Java 9
Posted by Mikael Ståldal <mi...@apache.org>.
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. :-)
Re: [Log4j] 2.9 release and Java 9
Posted by Remko Popma <re...@gmail.com>.
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. :-)
On Sun, Jul 9, 2017 at 8:13 PM, Mikael Ståldal <mi...@apache.org> wrote:
> As far as I understand, Java 9 will be released September 21.
>
> Now we plan to release Log4j 2.9 before the end of July.
>
> Given the problems that Java 9 causes, at least for Android, I suggest
> that we de-scope the Java 9 specific stuff (StackLocator) from the 2.9
> release.
>
> It should be possible to do a 2.10 release with the Java 9 specific stuff
> before September 21, right? And if not, that's not a disaster since the 2.9
> release will still work with Java 9 (just with non-optimal performance for
> locationInfo), right?
>
> I would say it's more important that log4j-api works on Android than we
> get optimal performance for locationInfo on Java 9. Especially now when
> Java 9 is not even officially released.
>