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 <alex.buck...@oracle.com> 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 via email to