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.reinh...@oracle.com wrote:
2015/2/5 12:40 +0000, david.ll...@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


Reply via email to