Multiple Versions vs "Module Hell"

[Nicolai Parlog]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 Hi David,

thank you for your answer. It was a very good one as it nudged me into
the right direction but still made me think. ;)

Here's what I came up with:

> What is the difference between more than one version of a module,
> and to different modules which happen to have very similar code in
> them?

Good point. Since "[m]ultiple modules may export packages of the same
name"[1] and the JVM "must prevent code from accessing classes and
interfaces [...] in packages whose containing modules are not required
by the module containing the code", we have everything we need.

Now we just have to act as if the two versions are two different
modules and we're done. If the runtime does not support this directly,
we could still do it manually by creating a new module for each
version, which simply reexports all published code, and redirect the
dependencies to those modules instead of the original one.

 Thanks ... Nicolai


[1] http://openjdk.java.net/projects/jigsaw/spec/reqs/02#exports
[2] http://openjdk.java.net/projects/jigsaw/spec/reqs/02#encapsulation



On 19.06.2015 15:17, David M. Lloyd wrote:
> It really comes down to the definition of "more than one version of
> a module".  What is the difference between more than one version of
> a module, and to different modules which happen to have very
> similar code in them?
> 
> On 06/19/2015 03:38 AM, Nicolai Parlog wrote: 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?
> 
> Thanks in advance Nicolai
> 
> 
> [1] blog.codefx.org/java/dev/motivation-goals-project-jigsaw/ [2]
> openjdk.java.net/projects/jigsaw/goals-reqs/ [3]
> http://openjdk.java.net/projects/jigsaw/spec/reqs/02 [4] 
> http://openjdk.java.net/projects/jigsaw/goals-reqs/03#multiple-version
s
>
> 
> 
> 
>> 
> 

- -- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVhVWaAAoJEMo7rS6czNUJBlsQAJtV7NJOtTVTFW95Do/UE6RU
W0QaFo0egxyTaXGz9/nQkECR1V3lgFnw2Evhh3n6hkv8McwZmXsS9tbAJqJ8fH/A
pRMioLMLoFUU9LGmPTJSo8uUinGH3+NKWytqOQ8bgrsEFg08+GFV6ZHdB9JDaQOh
htDpW/4/7v786g7rHgVQ41yOD3tuPbvvHkCKjA8lKKAMX/+QPNOOC+003/x6MzR7
EAqTCEQB2+Vr3vx6cfpgYLwvv5VEPxL3jczWi3V62gTVKNYXR2iMSNfggoOCQytt
KsQ3W8yDBGMbppr+zhGPwIWgcrjjUK0J8pF/HS3Ogc+upmrpDJK6HlFZJO/TG/eo
KUqScJa4aHilGv4iZ3KXANsnQqLQzg3XOcdIc4ApVmP0arPGX/q2ukH8qWkcVKqS
CHTo9dX4cCyl6kGVEZWP7gergiQ1YIgQHj4q4I7F5lJMY+WIpHEYkuy83oAEujQa
ueZ5/HjtKD8XqeXr+tONKqJyIiqT7OmMSX0fZ9dkSoTDZ9t4AXRlViabSCbL+NqM
+j8Wp1MjVxDuKlk8Al5JBHT7QKRmi2qWUGR1BNK5z7nLAiTVNVLEJdppqbU1cnoN
1ESb5ED9J9Cmh3oCzg3NHyPNaaG5a2/DVhpxU5vSdjh+R+y3ceRUs0qYMyGliPwt
cApKM/dH6vQlFasAw6XU
=/Nwq
-----END PGP SIGNATURE-----