On 29 October 2015 at 13:48, Alan Bateman <alan.bate...@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
