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.go...@dslextreme.com> > À: "core-libs-dev" <core-libs-dev@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
