On 30/10/2015 11:28, Stephen Colebourne wrote:
:
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.
The module system can facilitate many refactoring scenarios. This one
seems an incompatible change. Even if the module system supported
splitting a package between modules then it would force consumers of the
original module to change their module dependences.
- 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)
I assume if Guava wanted ImmutableList to be part of its API then it
would have made it public. In any case, testing a package private class
is a scenario that I can relate to. The -Xpatch option can help with
that. In the intro slide deck then there is an example, it's the in
"Director's cut", meaning the bonus slides after the presentation end slide.
- 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
Going forward then the ability to express dependences clearly should
help avoid the need to do this kind of thing.
-Alan.
