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 became a reality).

From maven (Eclipse Jetty 10.x is migrating to Slf4j 2.0.0-alpha1 btw).

 [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

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.