Conflicting module versions

[Gregg Wonderly]

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.

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.

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
>