Multiple versions of a non-exported dependency

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Multiple versions of a non-exported dependency

cowwoc
Administrator
Hi,

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"?

I hope that you did not drop version numbers altogether when dropping version-selection. Jigsaw should be able to map fixed version numbers (string literals) to different JAR files without having to understand the underlying versioning rules behind each string literal. Maven/OSGI could use their proprietary version-selection algorithms to select a specific version, generate a module-info.java containing that fixed version, and pass that to the JDK at build time. Would that not work?

If "requires" no longer takes a version number, I fear that you will never be able to add versioning support in the future...

Thanks,
Gili
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

Alex Buckley
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
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

Neil Bartlett
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]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

cowwoc
Administrator
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]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

Paul Benedict
Neil, but doesn't the prohibition of duplicate packages continue to rear
its head?

Cheers,
Paul

On Wed, Aug 31, 2016 at 2:21 PM, cowwoc <[hidden email]> 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
> > <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=
> unsubscribe_by_code&node=5713364&code=Y293d29jQGJicy5kYXJrdGVjaC5vcm
> d8NTcxMzM2NHwxNTc0MzIxMjQ3>.
> > 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.
>



--
Cheers,
Paul
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

forax
In reply to this post by Neil Bartlett
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]>
> À: [hidden email], "Alex Buckley" <[hidden email]>
> Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email]>
> 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]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

David M. Lloyd
In reply to this post by cowwoc
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
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

cowwoc
Administrator
In reply to this post by forax
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]>
> À: [hidden email], "Alex Buckley" <[hidden email]>
> Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email]>
> 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]> 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.
NAML


Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

Alex Buckley
In reply to this post by cowwoc
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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

cowwoc
Administrator
In reply to this post by David M. Lloyd
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.
NAML


Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

Alex Buckley
On 8/31/2016 12:39 PM, cowwoc wrote:
> I don't even care if you keep the current restrictions in place (allow
> only one version per layer)

There is no such restriction in the Java Platform Module System --
please look at java.lang.reflect.Layer. The restriction to a single
version of each module resides in the 'java' launcher [*] because we
don't want to change the class loading behavior of regular Java
applications.

Alex

[*] That's not the full story, as the boot layer with the application
loader has already been created by the time the launcher runs, but from
the user's point of view it's all "the 'java' launcher".
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

cowwoc
Administrator
In reply to this post by Alex Buckley
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.
NAML


Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

cowwoc
Administrator
In reply to this post by Alex Buckley
Alex,

I get this point but if "requires" does not take a version number today then the Java launcher can never add this functionality in the future. On the flip side, if you take a version string today and decide to drop it tomorrow ("this value is ignored in Java 12 and higher") there is minimal harm.

What's the downside here? How much work is involved in taking in this string?

Gili

On 2016-08-31 3:51 PM, Alex Buckley [via jigsaw-dev] wrote:
On 8/31/2016 12:39 PM, cowwoc wrote:
> I don't even care if you keep the current restrictions in place (allow
> only one version per layer)

There is no such restriction in the Java Platform Module System --
please look at java.lang.reflect.Layer. The restriction to a single
version of each module resides in the 'java' launcher [*] because we
don't want to change the class loading behavior of regular Java
applications.

Alex

[*] That's not the full story, as the boot layer with the application
loader has already been created by the time the launcher runs, but from
the user's point of view it's all "the 'java' launcher".



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-tp5713364p5713374.html
To unsubscribe from Multiple versions of a non-exported dependency, click here.
NAML


Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

Alex Buckley
In reply to this post by cowwoc
On 8/31/2016 12:51 PM, cowwoc wrote:
> 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.

We're not under this impression at all. The problem is that the cost of
solving incompatible indirect dependencies is high -- it would mean
introducing first-class versions and changing the class loading
characteristics of regular ('java'-launched) applications. Project
Jigsaw chose a long time ago to let tools handle the version selection
problem while it pursues other areas, namely strong encapsulation and
"modules all the way down" (the modular JDK). I see no reason why a
future project that wanted to introduce first-class versions couldn't do
it on top of JDK 9.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

cowwoc
Administrator
Alex,

Thank you for the clarification.

I am a bit confused by your assertion... If you wanted to introduce first-class versions in JDK 10, how would you do so (without breaking backwards compatibility) in light of this format?
module com.foo.bar {
    requires org.baz.qux;
}
Gili

On 2016-08-31 4:09 PM, Alex Buckley [via jigsaw-dev] wrote:
On 8/31/2016 12:51 PM, cowwoc wrote:
> 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.

We're not under this impression at all. The problem is that the cost of
solving incompatible indirect dependencies is high -- it would mean
introducing first-class versions and changing the class loading
characteristics of regular ('java'-launched) applications. Project
Jigsaw chose a long time ago to let tools handle the version selection
problem while it pursues other areas, namely strong encapsulation and
"modules all the way down" (the modular JDK). I see no reason why a
future project that wanted to introduce first-class versions couldn't do
it on top of JDK 9.

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-tp5713364p5713377.html
To unsubscribe from Multiple versions of a non-exported dependency, click here.
NAML


Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

Alex Buckley
This has been a good conversation but I'm unwilling to enter into
unbounded discussion of hypothetical future features. Here are some
practical things you can try with JDK 9 right now:

- Have you run your JDK 8 application on a JDK 9 EA build?
- Have you jlinked an image consisting of a handful of JDK 9 modules,
and run your application on top of that?
- Have you declared modules for your application and put supporting
legacy JARs on the modulepath as automatic modules?

Alex

On 8/31/2016 1:15 PM, cowwoc wrote:

> Alex,
>
> Thank you for the clarification.
>
> I am a bit confused by your assertion... If you wanted to introduce
> first-class versions in JDK 10, how would you do so (without breaking
> backwards compatibility) in light of this format?
>
> module com.foo.bar {
>       *requires*  org.baz.qux;
> }
>
> Gili
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

forax
In reply to this post by Alex Buckley
I think Alex is too gentle,
I don't want the JDK dictate to me how to resolve incompatible versions,
JBoss has it's own way to resolve versions, OSGI has another way, etc,
I don't want a n+1 way to resolve incompatible versions.

https://xkcd.com/927/

Rémi

----- Mail original -----
> De: "Alex Buckley" <[hidden email]>
> À: [hidden email]
> Envoyé: Mercredi 31 Août 2016 22:07:59
> Objet: Re: Multiple versions of a non-exported dependency

> On 8/31/2016 12:51 PM, cowwoc wrote:
>> 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.
>
> We're not under this impression at all. The problem is that the cost of
> solving incompatible indirect dependencies is high -- it would mean
> introducing first-class versions and changing the class loading
> characteristics of regular ('java'-launched) applications. Project
> Jigsaw chose a long time ago to let tools handle the version selection
> problem while it pursues other areas, namely strong encapsulation and
> "modules all the way down" (the modular JDK). I see no reason why a
> future project that wanted to introduce first-class versions couldn't do
> it on top of JDK 9.
>
> Alex
Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

cowwoc
Administrator
Remi,

I don't understand what you mean by "resolve incompatible versions". All I am asking the JDK to do is note the version number associated with a dependency and expose it using reflection for tools to use. Which part of this causes you problems?

Gili

On 2016-08-31 5:35 PM, Remi Forax [via jigsaw-dev] wrote:
I think Alex is too gentle,
I don't want the JDK dictate to me how to resolve incompatible versions,
JBoss has it's own way to resolve versions, OSGI has another way, etc,
I don't want a n+1 way to resolve incompatible versions.

https://xkcd.com/927/

Rémi

----- Mail original -----
> De: "Alex Buckley" <[hidden email]>
> À: [hidden email]
> Envoyé: Mercredi 31 Août 2016 22:07:59
> Objet: Re: Multiple versions of a non-exported dependency

> On 8/31/2016 12:51 PM, cowwoc wrote:
>> 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.
>
> We're not under this impression at all. The problem is that the cost of
> solving incompatible indirect dependencies is high -- it would mean
> introducing first-class versions and changing the class loading
> characteristics of regular ('java'-launched) applications. Project
> Jigsaw chose a long time ago to let tools handle the version selection
> problem while it pursues other areas, namely strong encapsulation and
> "modules all the way down" (the modular JDK). I see no reason why a
> future project that wanted to introduce first-class versions couldn't do
> it on top of JDK 9.
>
> 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-tp5713364p5713380.html
To unsubscribe from Multiple versions of a non-exported dependency, click here.
NAML


Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

cowwoc
Administrator
In reply to this post by Alex Buckley
Alex,

You wrote:

I see no reason why a
future project that wanted to introduce first-class versions couldn't do
it on top of JDK 9.

When I asked you to clarify how it could do so you responded with a non-answer. This doesn't inspire much confidence.

As far as I can tell, the current syntax makes this impossible.

Gili

On 2016-08-31 4:29 PM, Alex Buckley [via jigsaw-dev] wrote:
This has been a good conversation but I'm unwilling to enter into
unbounded discussion of hypothetical future features. Here are some
practical things you can try with JDK 9 right now:

- Have you run your JDK 8 application on a JDK 9 EA build?
- Have you jlinked an image consisting of a handful of JDK 9 modules,
and run your application on top of that?
- Have you declared modules for your application and put supporting
legacy JARs on the modulepath as automatic modules?

Alex

On 8/31/2016 1:15 PM, cowwoc wrote:

> Alex,
>
> Thank you for the clarification.
>
> I am a bit confused by your assertion... If you wanted to introduce
> first-class versions in JDK 10, how would you do so (without breaking
> backwards compatibility) in light of this format?
>
> module com.foo.bar {
>       *requires*  org.baz.qux;
> }
>
> Gili



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-tp5713364p5713379.html
To unsubscribe from Multiple versions of a non-exported dependency, click here.
NAML


Reply | Threaded
Open this post in threaded view
|

Re: Multiple versions of a non-exported dependency

Neil Bartlett
In reply to this post by forax
Remi,

Actually I don’t think that statically linking will work. This would produce modules that have overlapping private (non-exported) packages, and such modules also cannot be used in Java 9 on the modulepath.

I tested this in build 9-ea+126-jigsaw-nightly-h5280-20160713 by creating two modules both containing a private package org.example.util. The following exception resulted:  java.lang.reflect.LayerInstantiationException: Package org.example.util in both module a and module b.

Again this could be “solved” by using custom ClassLoaders or a ClassLoader-based module system like OSGi on Java 9.

Neil



> On 31 Aug 2016, at 20:28, Remi Forax <[hidden email]> 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]>
>> À: [hidden email], "Alex Buckley" <[hidden email]>
>> Cc: "ZML-OpenJDK-Jigsaw-Developers" <[hidden email]>
>> 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]> 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

123