Multiple Versions vs "Module Hell"

[Tim Boudreau]

On Fri, Jun 19, 2015 at 4:38 AM, Nicolai Parlog <nipa at codefx.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>  Hi!
>
> I am writing a series about Project Jigsaw[1] and am currently
> drafting an article about the planned features[2, 3].
>
> One paragraph in particular made me wonder:
>
>         "It is not necessary to support more than one version of a module
> within a single configuration."[4]
>
> At first sight this looks like it would create "Module Hell" instead
> of JAR Hell because instead of multiple JARs depending on different
> versions of the same JAR, we can now have multiple modules depending
> on different versions of the same module.
>
> I guess this is not so but I don't really see why not. I assume
> encapsulating the dependencies is the answer but it would be great to
> have a less speculative and vague explanation. Maybe someone on this
> list can help me out?
>

(reposting this to the list since I inadvertently replied only to Nicolai)

The key phrase is "It is not necessary".  That doesn't mean "it is
prohibited", just that a module system is not *required* to support doing
that to pass the test of being a faithful implementation of the module
system spec.

Many existing module systems do - for example, NetBeans module system (very
similar to OSGi but created several years earlier) allows that where it can
prove objects from library A-v1 can't possibly get mixed up with objects
from A-v2.

It's the sort of thing that's useful in large, modular applications that
are composed from parts that are dynamically loaded.  But it's just
pointless overhead in a small, self-contained application that's never
going to have those sorts of problems to solve.

So it makes sense, in defining the scope of the spec, that there's no
*requirement *to support that scenario.  There's no prohibition either.  As
long as there are ways to hook into the module discovery / loading process,
anybody who wants that can implement it, without it needing to be dictated
by the spec.

-Tim