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-----
