Android and Log4j

Ask Google to fix dx,
dx should ignore the module-info.class and everything inside META-INF/versions (at least it's a first simple patch).
cheers,
Rémi
----- Mail original -----
> De: "Ralph Goers" <ralph.goers at dslextreme.com>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Dimanche 3 Décembre 2017 19:25:08
> Objet: Android and Log4j
> Log4j added support for Java 9 by:
> Converting the Log4j-API jar to a multi-release jar that includes support for
> StackWalker and the new Process Id support.
> Adding a module-info.jar to the Log4j API jar.
>> We are now getting complaints from Android users (as well as a few others) that
> their tools no longer work with log4j. During development I ran into problems
> with OSGi. The problems seem to mostly revolve around the fact that they can’t
> deal with the classes for Java 9. I was surprised that Android is failing on
> the classes in META-INF/versions/9 as I had assumed that would be an invalid
> location for a class file prior to Java 9, but that seems not to be the case.
> The fact that module-info.java turns into a class file also seems to be a
> problem since the various tools are seeing it and having problems with it.
>> We have been discussing various ways to handle this in
>https://issues.apache.org/jira/browse/LOG4J2-2133> <https://issues.apache.org/jira/browse/LOG4J2-2133>. There seems to be a strong
> push to just remove the support for Java 9 since it is breaking so many things.
>> It seems impossible to have a module-info.java file in a jar that is going to be
> included in Android. If this had been a json file that was interpreted by the
> classloader or had a different file extension other than .class we wouldn’t be
> in this mess. We also need another mechanism to bring in our code that uses
> StackWalker as calling it via Reflection and emulating lambda expressions seems
> like it would be painful and slow.
>> Do you have any recommendations on how we can resolve this impasse?
>> Ralph