On Fri, Jun 19, 2015 at 4:38 AM, Nicolai Parlog <[email protected]> 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
