[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.i... ] Joakim Erdfelt commented on SLF4J-487: -------------------------------------- I'm not sure this is a bug in {{javac}}. Think about it, why would {{javac}} need to know runtime differences in order to compile? It doesn't know what the runtime will be, so it has to assume default behavior. Everything in the {{META-INF/versions/}} tree is optional behavior based on the runtime you are in. I'm curious to see what the {{javac}} maintainers say about it.

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)