I am aware of this approach, but this is precisely the kind of mess that I expected Jigsaw to replace.
As far as I know, the main reason JarJar came into existence was to work around "classpath hell" and the main goal behind Jigsaw was to solve it. For all of Jigsaw's accomplishments, it feels like it fails to solve the very problem it was designed to solve (maybe not Oracle's mind but certainly in the mind of most developers). Gili On 2016-08-31 3:29 PM, Remi Forax [via jigsaw-dev] wrote: > 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" <[hidden email] > </user/SendEmail.jtp?type=node&node=5713369&i=0>> > > À: [hidden email] </user/SendEmail.jtp?type=node&node=5713369&i=1>, > "Alex Buckley" <[hidden email] > </user/SendEmail.jtp?type=node&node=5713369&i=2>> > > Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email] > </user/SendEmail.jtp?type=node&node=5713369&i=3>> > > 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 <[hidden email] > </user/SendEmail.jtp?type=node&node=5713369&i=4>> 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 > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713369.html > > > To unsubscribe from Multiple versions of a non-exported dependency, > click here > <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5713364&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTcxMzM2NHwxNTc0MzIxMjQ3>. > NAML > <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > -- View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Multiple-versions-of-a-non-exported-dependency-tp5713364p5713371.html Sent from the jigsaw-dev mailing list archive at Nabble.com.
