Avoiding same-package conflicts

[Alex Buckley]

On 10/30/2015 1:38 PM, Jochen Theodorou wrote:
> I can second that by an example using Groovy. We have not yet taken
> steps to make jigsaw modules, but we quite some time ago we have split
> the code base in what would become eventually become modules in the
> future. Because of history this did mean to split packages. So we have a
> couple of jars (that want to be modules), with overlapping package names.
>
> Examples of package conflicts with the "base module":
>
> * The groovy-console has a conflict in groovy.ui
> * groovy-ant has a conflict in groovy.util
> * groovy-docgenerator in org.codehaus.groovy.tools
> * groovy-nio in org.codehaus.groovy.runtime
> * groovy-sql in org.codehaus.groovy.runtime
> * groovy-swing in org.codehaus.groovy.runtime
> * groovy-test in goovy.lang and groovy.util
> * groovy-xml in org.codehaus.groovy.runtime and goovy.util
>
> That's 7 "modules" with conflicts out of 19. One should remember here,
> that the codebase is like 10+ years old, and something that is now a
> "module" used to be fixed part of the language in the past. So some poor
> naming decision have been made. The org.codehaus.groovy.runtime
> conflicts could probably be solved, but the groovy.util ones are
> difficult, since this is a package imported by default (like java.lang
> in java), so moving classes to differing packages will break Groovy
> scripts... very elementary here for example GroovyTestCase in
> groovy-util, which is in the groovy-test "module"..

The initial modularization of JavaFX had a similar pattern: more split 
packages than you would think, due to a "horizontal" module wanting to 
share packages with numerous "vertical" domain modules. There, the 
"horizontal" module was a 'builder' module which hoped to add 
$COMPONENTBuilder classes to the packages of various 'component' 
modules; eventually the $COMPONENTBuilder classes were deemed 
unnecessary and the 'builder' module deleted. For Groovy, I suggest that 
your "base module" has the greatest claim to the 
org.codehaus.groovy.runtime package, and that the 
groovy-{nio,sql,swing,xml} modules should export 
org.codehaus.groovy.runtime.* subpackages to the base module only.

It doesn't seem great that the groovy-ant and groovy-test modules try to 
augment the important groovy.util package owned by your base module. 
Speaking generally, it makes no sense to allow a module to protect its 
internals if at the same time its API can be augmented by unrelated 
modules -- it can't be the "same" API because it doesn't have access to 
the same internals.

> also... there is a automated meta class lookup system, that is based on
> the package name with a prefix. So someone could provide a meta class
> for java.util.ArrayList, while another does this for LinkedList. If they
> are using modules, they cannot be loaded at the same time. Granted, I
> don't like this mechanism, and I am looking for ways to deprecate it in
> the near future, but it is another example of same-package conflicts.

Does this mean a Groovy meta class can currently be defined as a class 
in the java.* run-time package of the bootstrap loader?

Alex