Case - class from required module is not available

[Richard S. Hall]

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.

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.
>>
>>