Avoiding same-package conflicts

[Alan Bateman]

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.