Avoiding same-package conflicts

[Jochen Theodorou]

On 03.11.2015 22:28, Alex Buckley wrote:
[...]
> groovy-compiler will obviously have a hard dependency on groovy-base,
> but you can avoid groovy-base having a hard dependency on
> groovy-compiler by using services. Of course this assumes a suitable
> split between the interface of your compiler and its implementation.

and of course that split does not exist ;) It is a difference of not 
including something and referring to it by reflection, to have it 
optional; and to have it as a service. The first we can do without 
bigger changes, the later requires the definition of a whole "new" API.

[...]
> One option for the Groovy runtime is to special case its meta class
> package hierarchy by arranging for g.r.m.** classes to be defined by,
> and exported from, a special module that the runtime generates; the
> runtime would set up readability between this module and the user
> modules that "thought" they were defining and exporting g.r.m.**.
>
> You can see a flavor of this technique in the "dynamic module" created
> by Java's Core Reflection when you proxy certain interfaces -- see
> "Package and Module Membership of Proxy Class" in
> http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Proxy.html.

will have a look soon, thanks.

bye Jochen