Multiple versions of a non-exported dependency

[David M. Lloyd]

It seems like there is no good reason why the application modules aren't 
loaded with classloader-per-module now.  The platform stuff could all be 
in one, but the application stuff?  Problems like this are going to come 
up a lot otherwise; let's consider making that change.

On 08/31/2016 07:45 PM, Neil Bartlett wrote:
> 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 <forax at univ-mlv.fr> 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" <njbartlett at gmail.com>
>>> À: cowwoc at bbs.darktech.org, "Alex Buckley" <alex.buckley at oracle.com>
>>> Cc: "ZML-OpenJDK-Jigsaw-Developers" <jigsaw-dev at openjdk.java.net>
>>> 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 <alex.buckley at 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
>

-- 
- DML