[slf4j-dev] [JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9

[QOS.CH (JIRA)]

    [ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20359#comment-20359 ] 

Joakim Erdfelt commented on SLF4J-487:
--------------------------------------

{quote}
Finally, I should note that the reason the file is not being placed at the root is that it requires a minimum of Java 9. When the jar is used in applications and tools based on Java 8 or less they will have problems when they find the jar on the classpath. This is avoided by putting it under META-INF where java classes should not normally be found.
{quote}

Yes, I read SLF4J-456 and that's not a flaw in slf4j-api, but a bug in websphere.

I've said what I want to say, it's up to you and your development team to make the call on what you want to do.   I realize that slf4j-api and log4j are surely the early adopters here, but are not the only ones with this issue, adjusting your API jars to fit into the bugs of other products isn't a great long term solution IMO.

Meanwhile, I'll add links to the various web containers and their bugs / docs / issues / commits where the same JEP-238 issue occurs in many other libraries, just for the google karma and future researchers into this issue.

Note that +all+ of the existing servlet web containers have had to update their bytecode/annotation scanning for the realities of JEP-238 across many multitudes of JEP-238 artifacts.

* [jetty|https://github.com/eclipse/jetty.project/issues/1797] (committed Nov 2017)
* [tomcat|https://bz.apache.org/bugzilla/show_bug.cgi?id=61601] (committed Nov 2017)
* [websphere|https://github.com/OpenLiberty/open-liberty/pull/3057] (committed Apr 2018) ([support doc|https://www-01.ibm.com/support/docview.wss?uid=swg1PI96826] about it).
* [jboss/wildfly|https://access.redhat.com/solutions/3568471] - subscription based website, full solution requires membership.
* glassfish - the public issue repository (was at java.net) is now offline and I cannot link to the issue
* weblogic - no public accessibly issue repository

Thanks for hearing me out.
Feel free to close the issue if you feel I haven't sufficiently convinced you.

> module-info.class must be in root of jar, not META-INF/versions/9
> -----------------------------------------------------------------
>
>                 Key: SLF4J-487
>                 URL: https://jira.qos.ch/browse/SLF4J-487
>             Project: SLF4J
>          Issue Type: Bug
>          Components: Core API
>    Affects Versions: 2.0.0-alpha1
>         Environment: All environments
>            Reporter: Joakim Erdfelt
>            Assignee: SLF4J developers list
>
> Also reported here [https://github.com/qos-ch/slf4j/commit/fb418db538a4990#r37662713]
> This triggers build warnings on javac.
> The {{module-info.class}} shouldn't be in the {{META-INF/versions/9}} in the jar file, it should be in the root of the jar file.
> Yes, I'm aware of -SLF4J-456-, but that's a bug in websphere's annotation parsing (a similar bug that *all* web containers have had to fix since [JEP238|https://openjdk.java.net/jeps/238] became a reality).
> From maven (Eclipse Jetty 10.x is migrating to Slf4j 2.0.0-alpha1 btw).
> {noformat}
>  [INFO] — maven-compiler-plugin:3.8.1:compile (default-compile) @ jetty-slf4j-impl —
>  [INFO] Changes detected - recompiling the module!
>  [INFO] Compiling 9 source files to /home/joakim/code/jetty/jetty.project-10.0.x/jetty-slf4j-impl/target/classes
>  [WARNING] /home/joakim/code/jetty/jetty.project-10.0.x/jetty-slf4j-impl/src/main/java/module-info.java:[26,28] requires transitive directive for an automatic module
> {noformat}
> Using {{javac -Xlint:all ...}} on a project using {{slf4j-api-2.0.0-alpha1.jar}} with it's own {{module-info.class}} will show the above warning.
> If you want a small example project, I'll be happy to make one for you.
> The warning is because the {{module-info.class}} is not present at the root of the jar file (where it must be, despite the jigsaw devs brief suggestion in 2018 that {{META-INF/versions/9}} could be a solution for bytecode scanning problems, other tooling in the JDK hasn't caught up yet to that suggestion, even in JDK 14, even including {{javac}}).
> javac sees {{slf4j-api-2.0.0-alpha1.jar}} as having no {{module-info.class}} and is instead using the jar as one with an automatic module name.
> Manually repackaging {{slf4j-api-2.0.0-alpha1.jar}} with the {{module-info.class}} in the root fixes the javac warnings.



--
This message was sent by Atlassian JIRA
(v7.3.1#73012)