Conflicting module versions

[Tim Boudreau]

>
> So if nothing else, perhaps the formulation in the Jigsaw goals and
> requirements could be changed - the need for a *working* dependency
> resolution mechanism is clearly there.


The situation you described - Lib-v1 contains A and not B, and Lib-v2
contains B and not A, and application needs A and B, is unsolvable by any
dependency resolution mechanism that searches for contains-A and contains-B
(funny, I ran into this issue with Guava too, this evening - but the issue
there is really that Guava is too big and contains too much heterogenous
stuff jammed into one library for convenience).

The approach NetBeans' module system and others took to manage this was
classloader partitioning (i.e. two modules actually see different library
JARs).  Since Java is namespaced on packages, either you munge class names,
or classloading is the point where it's possible to intervene.  It could be
useful for a module system for Java to provide hooks to make it easy to
create per-module classloaders, but I don't think it should dictate that
for all applications, or make too many assumptions about what they do.

Maybe the place where it is best
> solved is not in Jigsaw, but it does seem like something that would fit
> squarely with the goals of the project and JSR, and it's in fact the only
> important classpath-brittleness issue I tend to come across.
>

When you say "dependency resolution mechanism", I'll bet everybody reading
it has a different definition of what that means.  Do you mean:
 - Thing that finds libraries on the internet and downloads them?
 - Thing that chooses among a bunch of local copies of different versions
of libraries and applies some algorithm to pick a version that will
definitely link?
    - At runtime?
    - At compile-time?
 - Thing that creates some amalgam of multiple library versions?
 - Something else?

I think it would be good to build a minimal module system, that makes it
easy to layer on top of it things that manage dependencies in a proactive
way, but I'd be wary of baking a One Right Way in unless it comes with
something close to a mathematical proof that it really can't be improved on.

I wrote some way, way out-of-the-box thoughts on the nature of libraries a
while back;  on some level, the root problem is that libraries are
human-created artifacts (a human decides a library's contents are, when its
version changes, what it's name is) to solve a problem that machines can do
better at if they ignore the fallible-human packaging piece altogether:
http://timboudreau.com/blog/libraries

-Tim