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