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
