On 02.11.2015 22:03, Alex Buckley wrote:
[...]
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.
Oh, I am not talking about internal API here.
The conflicts in org.codehaus.groovy.runtime are due to historic
reasons. They are mostly extension methods, which could be in any
package. But traditionally they had been part of DefaultGroovyMethods,
from which we factored out a lot of methods over time to modularize the
codebase more. And they tended to stay in the same package, since there
was in the past no reason to choose a different one... looks strange to
put a single class in a package that could be somewhere else perfectly
fine after all. If we move those classes to new packages, then we will
get into trouble with static compiled code. After all we did that
modularization before Groovy had an optional static compiler, and we did
a major version change for that (from 1.8 to 2.0) as well.
For groovy.util the case is more problematic. Moving GroovyTestCase into
a new package would for example break an estimated 95% of our test
cases. What will most likely happen is, that the test module merges with
the base module thus pulling in "optional" dependencies like JUnit 3...
which is in conflict with us trying to slim down the base runtime even
more, to for example give the android version an easier standing. We
have been thinking about for example moving the compiler into a separate
jar. But splitting something something as tightly coupled as that will
cause numerous same-package conflicts... Just to give an example... Eval
is a class in groovy.util and used for example like this:
assert 10 == Eval.me(' 2 * 4 + 2')
assert 10 == Eval.x(2, ' x * 4 + 2')
Of course this will call the compiler.. but what use is there to make a
groovy-base and a groovy compiler jigsaw style module, if they strongly
depend on each other anyway?
Anyway... my intension was to give an example of how some people divide
a broad library into "modules" and how it does not fit the "one module
per jar, no exported name space duplication" idea. And you just
confirmed it with the initial modularization of JavaFX.
Just to clarify... hiding parts of API is out of scope for groovy
modules atm. A first step for us would be to get some kind of mapping of
our current multi jar system to jigsaw modules that fits our needs.
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?
The class would be groovy.runtime.metaclass.java.util.ArrayListMetaClass
and doesn't have need the bootsrap loader for this of course. We
actually always avoided implementing logic that depends on being in the
bootstrap loader.
bye Jochen
