Avoiding same-package conflicts

[Jochen Theodorou]

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"..

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.

bye Jochen

On 30.10.2015 12:28, Stephen Colebourne wrote:
> On 29 October 2015 at 13:48, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> The restriction is that no two modules with the same package (irrespective
>> of whether it is exported or not, or who reads the modules) can be mapped to
>> the same class loader.
>
> FWIW, I think that this could be a headache for module adoption.
>
> Here are three cases that appear to be troubled by these restrictions:
>
> - a large project that has taken an existing project (module) and
> split it in two. In order to preserve backwards compatibility, the
> author wants to retain the package names. But doing so is not
> possible, because a single package now needs to be split across two
> modules.
>
> - extending a package scoped API from another project. While hardly
> pleasant this is sometimes the only viable approach to get a task
> done. As an example, the ImmutableList class from Google Guava has a
> package scoped constructor. It is perfectly possible today for an
> application to write a class that extends ImmutableList, so long as
> that class is placed in the com.google.common.collect package. The
> module system has the potential to block this extension point. (I
> imagine that cglib and similar tools also generate code in other
> peoples modules)
>
> - where a stable interface is copied into two separate jar files to
> avoid a dependency. An example of this was commons-beanutils where 4
> interfaces were copied from commons-collections. While this has now
> been changed, it was considered useful at the time, and given the
> stability of the interfaces in question, caused no problems.
> https://issues.apache.org/jira/browse/BEANUTILS-379
>
> FWIW, I'm most concerned about the first one going forward. However,
> the other two are cases I've seen used, and if used broadly in the
> wild could slow adoption (if it is hard to make those jar files
> modular, and they are widely depended on).
>
> Stephen
>