[
https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20356#comment-20356
]
Joakim Erdfelt commented on SLF4J-487:
--------------------------------------
I believe that section refers to runtime behavior, which is what JEP-238 is all
about.
However, runtime behavior is not applied at tooling / build / compile time (for
things like javac / IDE / code analysis / precompile / cache preload / bytecode
preload / quickstart calculation), which doesn't care about runtime differences
that JEP-238 provides and has to work with default behavior found in the JAR
files.
Here's that small example project I promised to demonstrate just maven and
javac behaviors - https://github.com/joakime/slf4j-487
Also, I've put together a demo class showing you what the JAR looks like to
java depending on use, by using the same tooling Java uses (the jarFs layer).
See:
https://github.com/joakime/slf4j-487/blob/runtime/src/main/java/org/example/JarBehaviorDemo.java
> 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
