Case - class from required module is not available

[Richard S. Hall]

On 3/28/12 13:24, Richard S. Hall wrote:
> On 3/28/12 6:34, David Holmes wrote:
>> On 28/03/2012 6:31 PM, Alan Bateman wrote:
>>> On 28/03/2012 02:48, David Holmes wrote:
>>>> On 28/03/2012 3:53 AM, Mandy Chung wrote:
>>>>> This is an interesting scenario - module c is linked with module b 
>>>>> only
>>>>> whereas module d is linked with module a only.
>>>>
>>>> So is that a bug or a feature? Given b will not be able to find a<1.0,
>>>> but a1.0 is already loaded, is it then necessary that b not be linked
>>>> to d?
>>> Right, a at 1.0 and b at 1.0 can't be the same configuration because of the
>>> constraint so the answer for d has to be {d at 1.0, a at 1.0} or {d at 1.0,
>>> b at 1.0}. There is code in the resolver that ensures that the 
>>> dependencies
>>> are examined in order so I assume this is why {d at 1.0, a at 1.0} is chosen.
>>> If d's dependencies are reversed then it will generate the other 
>>> answer.
>>> With c then the answer has to be {c at 1.0, b at 1.0}.
>>
>> Obviously there's a lot of detailed semantics here that I'm not clear 
>> on. Is this just an artifact of the current implementation strategy 
>> or a hard limitation in the overall model. My thinking is that b 
>> could still be made available to d as long as b's attempts to access 
>> anything in "a" give a "module not found" exception. But that all 
>> depends on how things are actually implemented.
>
> I would guess it is a hard limitation on the model. This is related to 
> "uses" constraints in OSGi. In OSGi, "uses" constraints are expressed 
> on exported packages and they specifically describe which other 
> imported/exported packages are used by a given exported package (i.e., 
> they are intra-module dependencies as opposed to the normal 
> inter-module dependencies). This allows OSGi to partition resolution 
> graphs in more fine-grained ways to support side-by-side types without 
> inconsistency issues.

Should have said, "...side-by-side versions..."

-> richard

>
> Since Jigsaw doesn't model "uses" constraints at all, the only thing 
> its resolver can do is assume that all required/exported types of a 
> given module are used by all its exported types, which means it has to 
> make coarser-grained decisions. So, in your case, it has to assume 
> that your D would be expecting to get A types from B if it were 
> resolved to both A and B. Thus, it cannot allow that since A isn't 
> satisfied for B and thus it can only allow D to resolve to A.
>
> -> richard
>
>>
>> Just curious.
>>
>> Thanks,
>> David
>>
>>> -Alan.
>>>
>>>