March 2020 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-488) Using slf4j-api-2.0.0-alpha1.jar not possible in OSGi
by QOS.CH (JIRA) 19 Mar '20

19 Mar '20

Joakim Erdfelt created SLF4J-488: ------------------------------------ Summary: Using slf4j-api-2.0.0-alpha1.jar not possible in OSGi Key: SLF4J-488 URL: https://jira.qos.ch/browse/SLF4J-488 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 2.0.0-alpha1 Environment: OSGi Reporter: Joakim Erdfelt Assignee: SLF4J developers list The ServiceLoader pieces of the {{META-INF/manifest.mf}} are missing for OSGi. It seems to be missing the {{Require-Capability}} entry to define ServiceLoader usage. Require-Capability=osgi.serviceloader;filter:="osgi.serviceloader=org.slf4j.spi.SLF4JServiceProvider)",osgi.extender;filter:="(osgi.extender=osgi.serviceloader.processor)" For example, here's the one out of {{javax.websocket}} {code} Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.servicelo ader.processor)",osgi.serviceloader;filter:="(osgi.serviceloader=javax. websocket.ContainerProvider)";resolution:=optional;cardinality:=multipl e,osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))" {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Release Announcement: General Availability of Java 14 / JDK 14
by Rory O'Donnell 18 Mar '20

18 Mar '20

Hi Ceki, **Release Announcement: General Availability of Java 14 / JDK 14 [1] * * * JDK 14, the reference implementation of Java 14, is now Generally Available. * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/14 * JDK 14 Release notes <https://www.oracle.com/technetwork/java/javase/14-relnote-issues-5809570.ht…> JDK 14 includes sixteen features [2]: 305: Pattern Matching for instanceof (Preview) 343: Packaging Tool (Incubator) 345: NUMA-Aware Memory Allocation for G1 349: JFR Event Streaming 352: Non-Volatile Mapped Byte Buffers 358: Helpful NullPointerExceptions 359: Records (Preview) 361: Switch Expressions (Standard) 362: Deprecate the Solaris and SPARC Ports 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector 364: ZGC on macOS 365: ZGC on Windows 366: Deprecate the ParallelScavenge + SerialOld GC Combination 367: Remove the Pack200 Tools and API 368: Text Blocks (Second Preview) 370: Foreign-Memory Access API (Incubator) Thanks to everyone who contributed to JDK 14, whether by creating features or enhancements, logging bugs, or downloading and testing the early-access builds. OpenJDK 15 EA build 14 is now available at http://jdk.java.net/15 * * * These early access, open source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Significant changes since the last availability email: o Build 13 - JDK-8238555 <https://bugs.openjdk.java.net/browse/JDK-8238555>: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB o Build 10 - JDK-8237776 <https://bugs.openjdk.java.net/browse/JDK-8237776>: Shenandoah: Wrong result with Lucene test + Reported by Apache Lucene. o Build 9 - JDK-8222793 <https://bugs.openjdk.java.net/browse/JDK-8222793>: Javadoc tool ignores "-locale" param and uses default locale for all messages and texts + Reported by Apache Lucene. Project Metropolis Early-Access Builds - Build 14-metropolis+1-17 <http://jdk.java.net/metropolis/> (2020/3/5) * These builds are intended for developers looking to test and provide feedback on using /Graal,/ in form of native library /(libjvmcicompiler.so)/, instead of C2 as HotSpot high optimizing JIT compiler. * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Please send feedback via e-mail to metropolis-dev(a)openjdk.java.net <mailto:metropolis-dev@openjdk.java.net>. To send e-mail to this address you must first subscribe to the mailing list <https://mail.openjdk.java.net/mailman/listinfo/metropolis-dev>. Regards, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004089.html [2] https://openjdk.java.net/projects/jdk/14 -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

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: ----------------------------------- 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