- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 08 Mar '20

08 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 08 Mar '20

08 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 08 Mar '20

08 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-487: ----------------------------------- I have submitted a bug report against javac. I will update with the bug number once I receive 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 06 Mar '20

06 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 06 Mar '20

06 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-487: ----------------------------------- Seeing as how Ceki and I both got information from the openjdk team to implement this by placing module-info.class in META-INF/services/9 and since the documentation I noted above clearly states that file need not be placed at the root I am inclined to conclude that the Warning that is generated by lint is a bug and should be opened with the JDK team. In addition, when running with the jar it behaves exactly as a JPMS module should. I also modified App.java in your project to list all the modules it found. It listed slf4j-api as a named module. Since META-INF/MANIFEST.MF does NOT contain Automatic-Module-Name this means it MUST have been located via its module-info. Executing "jar --file slf4j-api-2.0.0-alpha.jar --describe-module" results in {code:java} releases: 9 No root module descriptor, specify --release {code} jar --file slf4j-api-2.0.0-alpha.jar --describe-module --release 9 produces {code:java} releases: 9 org.slf4j jar:file:///Users/rgoers/projects/qos/log4j-module/mods/slf4j-api-2.0.0-alpha1.jar/!META-INF/versions/9/module-info.class exports org.slf4j exports org.slf4j.event exports org.slf4j.helpers exports org.slf4j.spi requires java.base mandated uses org.slf4j.spi.SLF4JServiceProvider {code} I would also note that the justification for the lint behavior can be found at [http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.…] where Mark is trying to warn users that they are using an Automatic Module. But since the runtime and jar tool are NOT treating it as an automatic module this clearly seems to be a bug in lint. Of course, Ceki is free to treat this as he wishes but seeing as how Log4j is doing the exact same thing I would treat this as a bug in lint since the jar works fine for every other purpose. > 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 06 Mar '20

06 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] 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… > 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 05 Mar '20

05 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-487: ----------------------------------- And to finish off the JEP-238 section. {noformat} A multi-release modular need not have a module descriptor at the located root. In this respect a module descriptor would be treated no differently to any other class or resource file. This can ensure that, for example, only Java 8 versioned classes are present in the root area while Java 9 versioned classes (including the module descriptor) are present in the 9 versioned area.{noformat} > 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 05 Mar '20

05 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] Joakim Erdfelt commented on SLF4J-487: -------------------------------------- The link to the section referenced - https://openjdk.java.net/jeps/238#Modular-multi-release-JAR-files You left out the part that the "Such versioned descriptors must be identical to the *root module descriptor*, with two exceptions ..." (emphasis mine). I'll prepare a small project demonstrating this issue with {{slf4j-api.2.0.0-alpha1.jar}}, upload it to github, and link here. > 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 05 Mar '20

05 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] Ralph Goers commented on SLF4J-487: ----------------------------------- Please see http://openjdk.java.net/jeps/238. {quote}A modular multi-release JAR file is a multi-release JAR file that has a module descriptor, module-info.class, in the root at the top, just like a modular JAR file (see the Packaging: Modular JAR section of JEP 261). In addition modular descriptors may be present in versioned areas.{quote} > 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)

1 0

[JIRA] (SLF4J-487) module-info.class must be in root of jar, not META-INF/versions/9
by QOS.CH (JIRA) 05 Mar '20

05 Mar '20

[ https://jira.qos.ch/browse/SLF4J-487?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-487: ---------------------------------- {quote}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. {quote} I believe I had tested for the proper treatment of the module-info,class when placed under META-INF/versions/9. Let me check again. > 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)

1 0