Avoiding same-package conflicts

[David M. Lloyd]

On 10/29/2015 05:59 AM, Martin Lehmann wrote:
> Hi all,
>
> I stumbled across the same "issue".
>
>> that having multiple versions of the same library isn't a best practice to say the least.
> Full ACK. Bad practice.

I disagree, actually.  I think that this is a completely needless and 
artificial restriction that arose from implementation decisions, not 
from a valid requirement.

We have used our ability to ship multiple modules with the same package 
names to good effect on more than one occasion.  As long as a given 
module doesn't link the conflicting packages, there is no real problem. 
  Even hypothetical issues involving indirect linkage or passing objects 
back and forth have never really been a problem for us.

> I might have an (artifical?) use case where this might lead to some extra effort in migration, though:
> Let's assume that two libraries D1 and D2 implement the same common API. For some historical reason, both libraries *ship* the interfaces classes of that common API.
> This won't work (easily) without repackaging jar files (even if the common API classes would not even differ).
>
> Example:
> A --requires --> B, C
> B --requires --> D1
> C --requires --> D2
> D1 and D2 both contain the same interfaces. Even if neither B nor C would *not* "requires public" D1 / D2, this would not work.
>
> Too artifical? I actually thought of two logging implementations using & shipping the common slf4j interface classes.
>
> So we really need disjunct classes in *all* libraries now? Not even, if the redundant packages are not even exported (right?). Would it work in the "old" classpath?

I think that judging by whether something would work in an old classpath 
is a false test.  The whole point of modules is to throw off the 
restrictions and problems of the classpath, after all.  I think a better 
test is, "does this make sense?", and to use your slf4j example - it 
definitely makes sense, because:

* Modules generally use slf4j as a private API to perform their own 
logging functions
* Thus slf4j generally never leaks to a module's exported package set
* Thus there's no actual harm in allowing this, and much benefit - 
especially if B and C (in your example) are not completely under your 
control (which is inevitable in any nontrivial system)

-- 
- DML