the acyclic module graph

Eric Johnson eric at tibco.com
Sat Dec 5 19:04:42 UTC 2015


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


More information about the jigsaw-dev mailing list