the acyclic module graph

[Jochen Theodorou]

for simplicity: app0 will talk with groovy.runtime only through static 
public methods or use public available classes.

if broken down to API visibility... groovy.runtime needs to be able to 
see (and use) everything, including private methods, from app0, while 
app0 can do with public methods and classes that are normally 
exported... well... I am not sure the bootstrap methods should be really 
public API, but since there is hardly another way..

bye Jochen

On 05.12.2015 20:04, Eric Johnson wrote:
> You might have to be more precise in your example.
>
> The runtime could define interfaces and classes that app0 could
> implement / extend. The modularity isn't about execution exclusion,
> but rather about API visibility.
>
> Eric
>
>> On Dec 5, 2015, at 9:16 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:
>>
>> Hi all,
>>
>> in the sadly few hours of my spare time these days I am trying to understand jigsaw better and I came across the condition that the module graph should be acyclic... which made me wonder...
>>
>>
>> So Let us assume there is a module groovy.runtime and a module app0, which is written in Groovy. groovy.runtime exports a equally named package for general use. Since app0 is written in Groovy there is the high possibility that I will have to invoke arbitrary methods from app0 from inside groovy.runtime. Meaning app0 needs to give a read edge to groovy.runtime for app0. So app0 depends on groovy.runtime and groovy.runtime depends on app0... is that a cricular dependency that is forbidden... or was it only for compile time?
>>
>> bye Jochen