I suppose we could have the log4j-api have a transitive dependency on log4j-api-java9 only when the build target is Java 9.
Ralph > On Dec 2, 2017, at 3:03 PM, Ralph Goers <[email protected]> wrote: > > 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]> >>>> >>> >>> >
