Question on Implied readability

[Ali Ebrahimi]

Thanks Alex,
So this is currently not fully implemented.
I think this would have many use cases in EE land where we would need
override some modules.

On Tue, Nov 3, 2015 at 5:57 AM, Alex Buckley <alex.buckley at oracle.com>
wrote:

> On 11/2/2015 3:32 PM, Ali Ebrahimi wrote:
>
>> On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>> On 02/11/2015 20:02, Ali Ebrahimi wrote:
>>> Thanks, I see the issue. The reason it didn't duplicate for me is because
>>> I hadn't dropped the requires com.bar.
>>>
>>> So the bug is implied readability across layers when the same named
>>> module
>>> exists in multiple layers. In this case com.foo should read com.bar at 1.
>>> The com.bar (@2) is the same configuration as com.foo is confusing the
>>> code. We'll need to fix this.
>>>
>>> So, you say com.foo can not read com.bar(@2) and why?
>>>
>> Based on implied readability module com.foo implicitly reads com.bar, in
>> other word have requires com.bar;
>> and because com.bar(@2) is co-layer with com.foo, so
>> module com.foo should reads com.bar(@2).
>> com.bar(@2) override com.bar(@1) for com.foo.
>> How this specified in spec?
>>
>
> It's currently underspecified in Configuration::resolve as "A readability
> graph is then constructed to take account of implicitly declared
> dependences (requires public)."
>
> We'll have to think about the implication of com.baz in layer1 sometimes
> offering a 'requires public' on com.bar in layer1, and sometimes offering a
> 'requires public' on com.bar in layer2, depending on who is reading com.baz
> in layer1.
>
> Alex
>



-- 

Best Regards,
Ali Ebrahimi