Multiple versions of a non-exported dependency

Wed Aug 31 19:51:46 UTC 2016

Alex,

I agree that the situation is better, but not by much. Developers 
routinely run across transitive dependencies that are incompatible with 
each other. You seem to be under the impression that this a rare 
occurrence or only occurs in the context of web containers, but this is 
simply not the case.

The current jigsaw implementation converts "classpath hell" failures 
from runtime to compile-time. While this is certainly an improvement I 
think we can do much better at a minimal implementation cost.

I propose having developers pass constant version numbers to "requires". 
You can keep all other restrictions in place (e.g. one version of each 
library) and hopefully we can loosen these restrictions in the future. 
If you're feeling extra generous, I would ask you to expose the version 
number through reflection (but, again this is not required up-front). I 
just want to lay the groundwork for future incremental improvement.

My fear is that if "requires" does not take a version number today, you 
will never be able to add it in future releases.

Gili

On 2016-08-31 3:39 PM, Alex Buckley [via jigsaw-dev] wrote:
> In the JDK 8 java launcher, classpath hell is having two [incompatible]
> versions of the "same" JAR on the classpath and getting types from both
> of them.
>
> In the JDK 9 java launcher, we avoid modulepath hell -- two
> [incompatible] versions of the "same" module on the modulepath -- by
> uniquifying each module on the modulepath. If someone tries to work
> around that by giving different names to the different versions of the
> "same" module, then we still avoid modulepath hell by refusing to load
> their [incompatible] packages into the same loader. The java launcher is
> not becoming a mini container that spins loaders for multiple versions
> of the same module -- code defined by the application loader on JDK 8 is
> defined by the application loader on JDK 9.
>
> Alex
>
> On 8/31/2016 12:21 PM, cowwoc wrote:
>
> > Well, this is unfortunate. As I stated earlier, I fail to see how
> > depending on constant version numbers (not version ranges) fall under
> > the scope of "version selection". Was this case considered/discussed in
> > depth?
> >
> > Not everyone is sold on version ranges (e.g. the vast majority of Maven
> > artifacts I've seen depend on constant versions) and I think this would
> > go a long way towards solving the original "classpath hell" problem.
> >
> > Gili
> >
> > On 2016-08-31 2:55 PM, Neil Bartlett [via jigsaw-dev] wrote:
> >> 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=5713366&i=0>> 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-tp5713364p5713366.html
> >>
> >> To unsubscribe from Multiple versions of a non-exported dependency,
> >> click here
> >> <
> >> 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-tp5713364p5713367.html
> > Sent from the jigsaw-dev mailing list archive at Nabble.com.
> >
>
>
> ------------------------------------------------------------------------
> 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-tp5713364p5713372.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-tp5713364p5713375.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.