Avoiding same-package conflicts
David M. Lloyd
david.lloyd at redhat.com
Thu Oct 29 11:33:01 UTC 2015
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).
> 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
* 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)
More information about the jigsaw-dev