Multiple Versions vs "Module Hell"

[Peter Firmstone]

Considering Java allows interfaces to evolve, with default methods, 
would it be beneficial to provide the ability in the jigsaw api to 
create API modules, with the intent of selecting common public api for 
backward compatible evolution, while also allowing different 
implementation modules, for whatever reason, to co-exist in the same 
runtime (loaded by different ClassLoaders).  Clients of the api may then 
be able to access the underlying module directly to access extending 
features; it encourages a common api for maximum sharing and compatibility.

Just a thought.

Cheers,

Peter.


On 20/06/2015 9:59 PM, Nicolai Parlog wrote:
> -----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-----
>