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 <[email protected]> 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
