[ 
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)
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/slf4j-dev

Reply via email to