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]>
>>
>
>
