[
https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20359#comment-20359
]
Joakim Erdfelt commented on SLF4J-487:
--------------------------------------
{quote}
Finally, I should note that the reason the file is not being placed at the root
is that it requires a minimum of Java 9. When the jar is used in applications
and tools based on Java 8 or less they will have problems when they find the
jar on the classpath. This is avoided by putting it under META-INF where java
classes should not normally be found.
{quote}
Yes, I read SLF4J-456 and that's not a flaw in slf4j-api, but a bug in
websphere.
I've said what I want to say, it's up to you and your development team to make
the call on what you want to do. I realize that slf4j-api and log4j are
surely the early adopters here, but are not the only ones with this issue,
adjusting your API jars to fit into the bugs of other products isn't a great
long term solution IMO.
Meanwhile, I'll add links to the various web containers and their bugs / docs /
issues / commits where the same JEP-238 issue occurs in many other libraries,
just for the google karma and future researchers into this issue.
Note that +all+ of the existing servlet web containers have had to update their
bytecode/annotation scanning for the realities of JEP-238 across many
multitudes of JEP-238 artifacts.
* [jetty|https://github.com/eclipse/jetty.project/issues/1797] (committed Nov
2017)
* [tomcat|https://bz.apache.org/bugzilla/show_bug.cgi?id=61601] (committed Nov
2017)
* [websphere|https://github.com/OpenLiberty/open-liberty/pull/3057] (committed
Apr 2018) ([support
doc|https://www-01.ibm.com/support/docview.wss?uid=swg1PI96826] about it).
* [jboss/wildfly|https://access.redhat.com/solutions/3568471] - subscription
based website, full solution requires membership.
* glassfish - the public issue repository (was at java.net) is now offline and
I cannot link to the issue
* weblogic - no public accessibly issue repository
Thanks for hearing me out.
Feel free to close the issue if you feel I haven't sufficiently convinced you.
> 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
