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 <[email protected]> wrote: > On Mon, Jul 10, 2017 at 2:52 PM, Gary Gregory <[email protected]> > wrote: > > > > > > > On Jul 10, 2017 14:40, "Matt Sicker" <[email protected]> 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 <[email protected]> > 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 <[email protected] > > > > > wrote: > > > > > > > > > > > >> On Jul 10, 2017, at 1:31 PM, Gary Gregory <[email protected]> > > > 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 <[email protected]> > > > > > > > -- Matt Sicker <[email protected]>
