I don't disagree.
By requiring developers to provide constant version numbers we kill two
birds with one stone:
* We solve part of the "classpath hell" problem out-of-the-box.
* We future-proof the specification so version handling can be
extended in the future.
If "requires" does not take a version number today, adding it tomorrow
might very well be impossible.
I don't even care if you keep the current restrictions in place (allow
only one version per layer) so long as the specification collects
version numbers from day one. This will allow you to ease the
1-version-per-layer restriction in the future without breaking backwards
compatibility for existing deployments.
Gili
On 2016-08-31 3:30 PM, David M. Lloyd [via jigsaw-dev] wrote:
> There are two dimensions to the version range issue: build
> reproducibility and future-proofing.
>
> In the former category, single versions are generally used for build
> because that ensures that the build will not change over time as new
> versions of things become available. In other words, I build version X
> of my module on Monday or on Friday and I get the same bits in the end
> (more or less). Depending on a version range means that a newer version
> of a thing becoming available to the build environment can potentially
> cause a change in the final artifact, so version ranges are clearly not
> good for the build phase.
>
> In the latter category, and this is really the primary motivator for
> having version ranges in the first place, there is a desire for the
> developer to stipulate that a module will work with a range of versions
> of another module. Thus specifying a range of such versions is
> desirable. However this is really a test phase concern: you really only
> get an idea of compatibility with some version of a dependency after it
> has been tested or after some other process wherein such a compatibility
> can be reliably asserted. Furthermore, the range of compatibility may
> be found to have changed over the lifetime of a single version of a
> given artifact, such that one may wish to add or remove versions from
> the known-to-be-compatible set. Thus this kind of information cannot
> and should not be part and parcel with the artifact itself; rather it
> belongs to the repository or distribution which hosts the artifact, and
> to which (for example) a CI system may refer.
>
> On 08/31/2016 02: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.
> >
>
> --
> - DML
>
>
> ------------------------------------------------------------------------
> 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-tp5713364p5713370.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-tp5713364p5713373.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.
