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

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

The answer to this is fairly straightforward. Your compile target has to be Java 9 or greater else you wouldn't be trying to resolve Java modules. Therefore, the compiler should honor whatever classes are specified in META-INF/versions/n that matches the target/release version. For example, it is perfectly allowable to have classes in META-INF/versions/9 that do not exist in the base version. Classes compiling for Java 9 or later must be able to reference those classes, providing they are publicly exposed.  

So it is not really accurate to classify them as "optional". They are required based on the target you are compiling against.

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