the acyclic module graph
blackdrag at gmx.org
Sun Dec 6 09:27:38 UTC 2015
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..
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.
>> 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
More information about the jigsaw-dev