Conflicting module versions

[David M. Lloyd]

Comments inline.

On 02/06/2015 11:17 PM, Gregg Wonderly wrote:
> I'd personally prefer that a dependency graph with branches such as
>
> A->C
> A->B.v1
> C->B.v2
>
> be resolved with both version of B loaded and a ClassLoader hierarchy
> that puts each version of B's parent class loader pointing at
> the same classloader that A and C are loaded with.   A and C may not use
> B in any common code paths and objects from B.v1 never
> be confused with objects from B.v2.  Demanding that only one version of
> B be loaded is extremely short sighted.  That demands that the author of
> A be in control of the evolution of both C and B which may never be
> possible.

This kind of multi-versioning is not precluded by a cohesive version set 
in a distribution; in fact it's actually a function of it.  In JBoss 
Modules for example, there is no actual difference between two versions 
of one module compared to two distinct modules.  But again it's a 
distribution problem to ensure that the correct modules link against 
their correct dependencies and to ensure that such linkage doesn't 
result in undesirable interactions.  There is to my knowledge no 
algorithm that can automatically make these kinds of decisions without a 
polynomial-scale increase in complexity, which at run time is Not Cool.

> Demanding that only one version of B can exist will pretty much keep me
> and a lot of other people from caring about or contributing to what
> might happen with this JSR.

I don't think it's a question of caring, nor do I think there's a 
one-dimensional cleanliness-versus-pragmatic axis that we must place 
ourselves on.  In other words, this is a bit of a straw man.

> Yes you can want a pretty world.  Practically, there is no way that you
> can dictate how people develop software and how it should interact.
>
> Gregg Wonderly
>
> On 2/5/2015 7:00 AM, mark.reinhold at oracle.com wrote:
>> 2015/2/5 12:40 +0000, david.lloyd at redhat.com:
>>> I agree that working dependency resolution is a necessity for a working
>>> software system.  But, it is my opinion that run time is far too late
>>> for this to occur (and I intend to carry this opinion into the JSR
>>> working group).  Ultimately it is up to the module distributor to ensure
>>> that their distribution contains a cohesive module set.  While it is
>>> possible to efficiently add certain types of validation checks at run
>>> time, by this time it is far too late to do anything about a violation
>>> other than just fail.
>> Broadly speaking, I agree.  At run time a module system should prevent
>> broken situations such as conflicting module versions.  It need not,
>> however, attempt to solve them -- that's really hard, and it generally
>> requires human intervention in order to identify the correct version.
>> Simply failing in such scenarios (with a good error message, of course)
>> is perfectly acceptable.
>>
>> - Mark
>>
>

-- 
- DML