[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=20358#comment-20358 ] 

Ralph Goers commented on SLF4J-487:
-----------------------------------

Seeing as how Ceki and I both got information from the openjdk team to implement this by placing module-info.class in META-INF/services/9 and since the documentation I noted above clearly states that file need not be placed at the root I am inclined to conclude that the Warning that is generated by lint is a bug and should be opened with the JDK team.  In addition, when running with the jar it behaves exactly as a JPMS module should.  

I also modified App.java in your project to list all the modules it found. It listed slf4j-api as a named module. Since META-INF/MANIFEST.MF does NOT contain Automatic-Module-Name this means it MUST have been located via its module-info.

Executing "jar --file slf4j-api-2.0.0-alpha.jar --describe-module" results in 

 
{code:java}
releases: 9
No root module descriptor, specify --release
{code}
 

jar --file slf4j-api-2.0.0-alpha.jar --describe-module --release 9 produces

 
{code:java}
releases: 9
org.slf4j jar:file:///Users/rgoers/projects/qos/log4j-module/mods/slf4j-api-2.0.0-alpha1.jar/!META-INF/versions/9/module-info.class
exports org.slf4j
exports org.slf4j.event
exports org.slf4j.helpers
exports org.slf4j.spi
requires java.base mandated
uses org.slf4j.spi.SLF4JServiceProvider
{code}
 

I would also note that the justification for the lint behavior can be found at [http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html] where Mark is trying to warn users that they are using an Automatic Module. But since the runtime and jar tool are NOT treating it as an automatic module this clearly seems to be a bug in lint. 

Of course, Ceki is free to treat this as he wishes but seeing as how Log4j is doing the exact same thing I would treat this as a bug in lint since the jar works fine for every other purpose.

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