Avoiding same-package conflicts
blackdrag at gmx.org
Fri Nov 6 20:07:44 UTC 2015
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
will have a look soon, thanks.
More information about the jigsaw-dev