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.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
--
- DML
