So this is the other problem. It is complaining that it doesn’t support Java 9 class files. That would be module-info.java I am sure.
Ralph > On Dec 2, 2017, at 2:02 PM, Gary Gregory <[email protected]> wrote: > > Here you go, from one of my work projects: > > [WARNING] Unable to process class module-info.class in JarAnalyzer File > C:\Users\ggregory\.m2\repository\org\slf4j\slf4j-api\1.8.0-alpha2\slf4j-api-1.8.0-alpha2.jar > org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in > constant pool: 19 > at org.apache.bcel.classfile.Constant.readConstant (Constant.java:167) > at org.apache.bcel.classfile.ConstantPool.<init> (ConstantPool.java:66) > at org.apache.bcel.classfile.ClassParser.readConstantPool > (ClassParser.java:239) > at org.apache.bcel.classfile.ClassParser.parse (ClassParser.java:144) > at org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze > (JarClassesAnalysis.java:96) > at > org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails > (Dependencies.java:259) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed > (DependenciesRenderer.java:1542) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails > (DependenciesRenderer.java:545) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody > (DependenciesRenderer.java:240) > at org.apache.maven.reporting.AbstractMavenReportRenderer.render > (AbstractMavenReportRenderer.java:83) > at org.apache.maven.report.projectinfo.DependenciesReport.executeReport > (DependenciesReport.java:201) > at org.apache.maven.reporting.AbstractMavenReport.generate > (AbstractMavenReport.java:255) > at > org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument > (ReportDocumentRenderer.java:229) > at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render > (DefaultSiteRenderer.java:337) > at org.apache.maven.plugins.site.render.SiteMojo.renderLocale > (SiteMojo.java:178) > at org.apache.maven.plugins.site.render.SiteMojo.execute > (SiteMojo.java:132) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:134) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:154) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:146) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:51) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:194) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke (Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:356) > > Gary > > On Sat, Dec 2, 2017 at 11:49 AM, Gary Gregory <[email protected]> > wrote: > >> I think Slf4j 1.8-alpha has the same problem, not 100% sure. >> >> Gary >> >> On Sat, Dec 2, 2017 at 11:03 AM, Matt Sicker <[email protected]> wrote: >> >>> Are there other Java 9 ready libraries that are having the same problem in >>> Android? >>> >>> On 2 December 2017 at 10:40, Ralph Goers <[email protected]> >>> wrote: >>> >>>> FWIW, it would make sense to me to make a log4j-core-android that is a >>>> subset of what is in core, if that is possible. Of course, the API >>> problem >>>> has to be solved first. >>>> >>>> Ralph >>>> >>>> >>>>> On Dec 2, 2017, at 9:38 AM, Ralph Goers <[email protected]> >>>> wrote: >>>>> >>>>> I see several issues: >>>>> >>>>> StackLocator: >>>>> This cannot be removed from the API is the API as >>>> LogManager.getLogger() calls it. Converting the Java 9 version to use >>>> Reflection would add enough overhead that it probably wouldn’t be worth >>> it >>>> to use it. Also, you would have to figure out how to code the lambda >>>> expressions without using Lambdas. Adding a log4j-java9 jar for api >>> and/or >>>> core would probably make us as unpopular with folks migrating to Java 9 >>> as >>>> the current situation is for Android users, but it may be the only >>> viable >>>> solution. Figuring out how to have the class files be ignored by Android >>>> seems reasonable but nothing immediately comes to mind as to how to do >>> it. >>>>> >>>>> I made a log4j-android branch a while back that operates pretty much >>> as >>>> Remko describes below. It does not include the Java 9 support and >>> includes >>>> a binding to the android logger. However, I got an immediate complaint >>> from >>>> an Android user that they were not happy with that as they wanted >>> access to >>>> core. It is also a problem to have lots of pom files refer to log4j-api >>> and >>>> to have to exclude that and replace it with log4j-android instead. >>>>> >>>>> I do not want to drop support for Java 9 but we do need to find a >>>> creative solution for StackLocator. The limitations I am aware of with >>> this >>>> are that having multi-release jars and/or Java 9 classes in the jar >>> cause >>>> problems with tools. Also, having Java 9 source directly in log4j-api or >>>> log4j-core does not play nice with IDEs. >>>>> >>>>> The only thing that comes to mind with regarding having classes with a >>>> different file extension would be to have a custom class loader that >>> wraps >>>> whatever the class loader is. Going down that road seems like it could >>> be >>>> full of problems. >>>>> >>>>> Ralph >>>>> >>>>> >>>>> >>>>> >>>>>> On Dec 2, 2017, at 7:34 AM, Remko Popma <[email protected]> >>> wrote: >>>>>> >>>>>> Ok, you have some fair points there. >>>>>> >>>>>> Main take-away for me is that if we want Log4j2's API to become >>>> ubiquitous >>>>>> it needs to be at least painless for everyone. >>>>>> Don't known about the "too much stuff" in log4j-api - bit vague and >>> not >>>>>> actionable. >>>>>> >>>>>> What can we do, concretely? >>>>>> >>>>>> log4j-api >>>>>> --------- >>>>>> 1) I've already replaced the explicit references to JMX classes in >>>>>> log4j-api with reflection for Android compatibility. (LOG4J2-2126 >>>>>> <https://issues.apache.org/jira/browse/LOG4J2-2126> was a >>> regression, >>>> fixed >>>>>> now) >>>>>> 2) The tricky bit is StackLocator. Options I can think of: >>>>>> a) reflection; >>>>>> b) separate log4j-api-java9 jar; >>>>>> c) rename java 9 class files to other extension than .class and >>> load at >>>>>> runtime when running in Java 9 >>>>>> d) other? >>>>>> 3) The PID stuff can be moved to core (would still need some solution >>>> like >>>>>> for above (2) to allow use in Android). >>>>>> >>>>>> >>>>>> log4j-core >>>>>> ---------- >>>>>> We don't really have a good Android story for core. >>>>>> >>>>>> One option we can offer is log4j-api-android, which is a drop-in >>>>>> replacement for log4j-core that logs to Android's adb, similar to >>> what >>>>>> "android.util.Log.d" does. However, we've had feedback from users who >>>> want >>>>>> to use normal log4j-core file logging facilities on Android >>> (LOG4J2-1921 >>>>>> <https://issues.apache.org/jira/browse/LOG4J2-1921>). >>>>>> >>>>>> Maybe we can do the same for log4j-core as for log4j-api: use >>>> reflection or >>>>>> even separate jars :-( to make log4j-core work in Android. >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Dec 2, 2017 at 8:09 PM, Mikael Ståldal <[email protected]> >>>> wrote: >>>>>> >>>>>>> I fully understand Oleg's point of view. >>>>>>> >>>>>>> If we aim for Log4j 2's API to be the standard logging API/facade >>> for >>>>>>> Java/JVM (eventually replacing SLF4J), then we have painted >>> ourselves >>>> into >>>>>>> a corner by allowing log4j-api to grow out of bounds, and not paying >>>> enough >>>>>>> attention to the compatibility problems with Android (and possibly >>>> fringe >>>>>>> platforms) it causes. >>>>>>> >>>>>>> It is quite pointless to blame this on Android and its tooling. We >>> can, >>>>>>> and should raise issues we find on Android tooling, and hope for >>> them >>>> to >>>>>>> eventually get fixed. But that can take time, and at the end of the >>> day >>>>>>> Android is what it is, and that's what users are going to use. If >>>> log4j-api >>>>>>> does not work on Android, most users will blame Log4j and not >>> Android. >>>>>>> >>>>>>> And if a library with use cases both on standard Java and on >>> Android, >>>> like >>>>>>> Apache HttpClient, have a required dependency on log4j-api and that >>>> causes >>>>>>> it to fail on Android, most users will blame HttpClient and not >>> Android >>>>>>> (nor Log4j since they may be unaware of it). >>>>>>> >>>>>>> If I were maintainer of Apache HttpClient, I would also be very >>>> hesitant >>>>>>> to make it depend on log4j-api at this point. I don't think it is >>>>>>> constructive to just try to convince them given the current state of >>>> Log4j >>>>>>> and the Android tooling, we need to do some work on our end first >>> (or >>>>>>> possibly volunteer to spend some effort on fixing the Android >>> tooling). >>>>>>> >>>>>>> I think that the root cause is not Java 9 support, it is that we >>> have >>>>>>> allowed too much stuff to go into log4j-api (instead of log4j-core), >>>> and >>>>>>> that started long before the Java 9 work. JMX is also incompatible >>> with >>>>>>> Android, regardless of Java 9. >>>>>>> >>>>>>> With a thinner log4j-api, we could have added Java 9 support to >>>> log4j-core >>>>>>> only, and avoided this problem. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2017-12-01 15:53, Gary Gregory wrote: >>>>>>> >>>>>>>> I had migrated HttpClient 5 to Log4j 2 but now there is push back >>> due >>>> to >>>>>>>> the mess Java 9 has made of the META-INF folder and our adding >>>> support for >>>>>>>> Java 9 modules perhaps too soon. >>>>>>>> >>>>>>>> Please see http://markmail.org/message/yyoj4zs3ieyaept5 and >>> comment >>>> on >>>>>>>> that >>>>>>>> thread please. >>>>>>>> >>>>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >>> >> >>
