The other solution is to statically link the right version of slf4j inside guava and jsoup. A tool like jarjar can be updated to merge two modular jars (merge two module-info).
cheers, Rémi ----- Mail original ----- > De: "Neil Bartlett" <njbartl...@gmail.com> > À: cow...@bbs.darktech.org, "Alex Buckley" <alex.buck...@oracle.com> > Cc: "ZML-OpenJDK-Jigsaw-Developers" <jigsaw-dev@openjdk.java.net> > Envoyé: Mercredi 31 Août 2016 20:54:44 > Objet: Re: Multiple versions of a non-exported dependency > Gili, > > As Alex points out: your use-case can be supported in Java 9 but only with the > addition of custom ClassLoaders, or by using an existing ClassLoader-based > module system such as OSGi. > > The same is also true of Java 8, and Java 7, etc. > > Regards, > Neil > > >> On 31 Aug 2016, at 19:29, Alex Buckley <alex.buck...@oracle.com> wrote: >> >> On 8/31/2016 10:56 AM, cowwoc wrote: >>> I recently became aware of the fact that the Jigsaw specification declared >>> "version-selection" as a non-goal. While I understand how we ended up here, >>> I am hoping that you were able to support the following (very common) >>> use-case: >>> >>> * Module "HelloWorld" depends on modules "Guava" and "JSoup". >>> * Module "Guava" depends on module slf4j version 1 (requires but does not >>> export it). >>> * Module "JSoup" depends on module slf4j version 2 (requires but does not >>> export it). >>> * slf4j version 2 and is not backwards-compatible with version 1. >>> >>> What happens at runtime? Will Jigsaw (out of the box, without 3rd-party >>> tools like Maven or OSGI) be smart enough to provide different versions of >>> slf4j to "Guava" and "JSoup"? >> >> (You mean Guava/JSoup requires slf4j version 1/2 and does not "re-export" it >> a.k.a. 'requires public'.) >> >> This use case isn't possible on JDK 8 for JARs on the classpath, and it's not >> supported on JDK 9 for modular JARs on the modulepath: >> >> - If you have two versions of a modular JAR slf4j.jar in different >> directories >> on the modulepath, then the first one to be found will dominate, and that's >> what will be resolved for both Guava and JSoup. >> >> - If you have two modular JARs slf4j_v1.jar and slf4j_v2.jar on the >> modulepath, >> and Guava requires slf4j_v1 and JSoup requires slf4j_v2, then launching 'java >> -m HelloWorld' will fail. The boot layer will refuse to map the "same" >> packages >> from different slf4j_v* modules to the application class loader. >> >> The use case _is_ supported on JDK 9 for modular JARs loaded into custom >> loaders >> of custom layers. That is, the Java Platform Module System is perfectly >> capable >> of supporting the use case -- please see any of my "Jigsaw: Under The Hood" >> presentations. The use case just isn't supported "out of the box" by the >> 'java' >> launcher for JARs on the modulepath. >> > > Alex
