Module descriptions versus module descriptors

Fri Jan 15 13:47:40 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

 Hi!

Sorry to revive this old thread...

> I think this is largely a question of interpretation.  Is there
> any practical difference between two versions of one module versus
> two unrelated modules?  Perhaps the only distinction between these
> two concepts is that, in the "multi-version" case, two modules
> have packages of the same designation.

A class loader will refuse to load two modules that export the same
packages. So renaming a module to launch with two different versions
doesn't work.

 so long ... Nicolai

On 12/15/15 21:28, David M. Lloyd wrote:
> I think this is largely a question of interpretation.  Is there
> any practical difference between two versions of one module versus
> two unrelated modules?  Perhaps the only distinction between these
> two concepts is that, in the "multi-version" case, two modules have
> packages of the same designation.
> 
> However there are two real-world cases which hamper this view of
> the world:
> 
> * There are cases where new versions of APIs exist which do not
> have any package overlap with certain earlier versions of those
> same APIs, even if they did overlap over their interim lifespan. *
> There are cases where two otherwise unrelated modules might have
> the same package(s) in them for various reasons unrelated to
> versioning or anything else previously mentioned (like slf4j
> implementations for example).
> 
> So in this regard, I think that "multiple versions" is really just
> a social facade over distinct modules, and I really believe that
> distinct modules are the best representation of this concept in
> the deployment/execution phase(s) of system development.
> 
> The places where multiple version management becomes more
> "interesting" are during build, and during unit and integration
> test.  This is where the upstream artifacts - typically
> individually versioned - must ultimately be resolved to their
> simple (effectively versionless) deployment/execution phase
> variants, and where changes to the run time environment must be
> tested for compatibility and regression.  But in this regard, there
> is a logical "wall" between the many-version universe of, say,
> Maven Central versus the tightly-controlled, tested universe of the
> final deployment.
> 
> I personally consider the upstream artifact part of this puzzle to 
> essentially be a well-solved problem, thanks to Maven's
> widely-adopted artifact repository scheme and others like it.
> 
> On 12/15/2015 01:57 PM, Paul Benedict wrote:
>> Okay, I will continue with your example of 3.x vs 4.x...
>> 
>> Part of the hope that I had for Java Modules was the ability to
>> remove tricks. A popular trick today, when needing to run with
>> multiple versions of a library, is to either (1) shade it or (2)
>> develop the code in a different package. Both are just the form
>> of same trick depending on whether you own the code or not.
>> Regarding Commons Collections, that's why v3 is in the
>> "collections" package but v4 is in the "collections4" package;
>> otherwise, you can't use both in your classpath.
>> 
>> With that said, I think it should be possible to eliminate both
>> shading and package renaming in a properly encapsulated system.
>> As long as I am not re-exporting my dependencies, none of my
>> dependencies will leak transitively. This means it should be
>> easily possible to support multiple versions at runtime.
>> Unfortunately, the Jigsaw spec says multiple versions are not
>> supported [1]. So that means in a real-world system where
>> multiple versions are required, you're back to doing trickery. Is
>> adding opaque numbers to modules the next trick?
>> 
>> [1]
>> http://openjdk.java.net/projects/jigsaw/spec/reqs/#multiple-versions
>>
>>
>> 
Cheers,
>> Paul
>> 
>> On Tue, Dec 15, 2015 at 1:22 PM, David M. Lloyd
>> <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>> 
>> On 12/15/2015 12:53 PM, Paul Benedict wrote:
>> 
>> On Tue, Dec 15, 2015 at 12:39 PM, David M. Lloyd 
>> <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com> 
>> <mailto:david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>>> 
>> wrote:
>> 
>> I think that this use case is supported by the requirements.
>> While the requirements explicitly do not support multiple 
>> versions of modules, it is easy enough to package each version as
>> a separate module with a different name, e.g. 
>> "org.apache.commons.collections.3.2" vs. 
>> "org.apache.commons.collections.3.3" or some such, optionally
>> using a module alias to choose one of these to be the proper 
>> "org.apache.commons.collections" module.
>> 
>> 
>> The SOTMS makes it clear the "convention" is to use the package 
>> name as the module name. My example is based on that convention.
>> If versioning is always going to be an issue, that statement
>> cannot hold true. Besides, I think putting the version in the
>> module name defeats one of the design assumptions: the ability to
>> swap in newer versions that are different than what was compiled
>> against. In a world where semver is practiced perfectly, 3.3
>> should be able to be subbed for 3.2.
>> 
>> 
>> Ah, I took your question to be literally about the original 
>> requirements document.  Yes, the SOTMS document makes further 
>> assumptions and recommendations beyond the original
>> requirements.
>> 
>> That said, my reading of SOTMS doesn't forbid what I've stated
>> above - it does indeed state that "The name of a module will,
>> therefore, often be a prefix of the names of its exported
>> packages, but this relationship is not mandatory".  The SOTMS
>> document furthermore does not appear to forbid numeric segments
>> in module names, though it does say "A module's declaration does
>> not include a version string, nor constraints upon the version
>> strings of the modules upon which it depends", which one might
>> interpret as forbidding this.  Even if numeric segments were not
>> allowed, however, the problem could be addressed easily by using
>> e.g. ".v3_2" instead of ".3.2".
>> 
>> In a world of perfect semantic versioning, you probably wouldn't 
>> have 3.2 vs 3.3 modules; you'd just have the latest 3.x which is 
>> shared by everyone, and maybe someday you might also have a 4.x; 
>> doing so would require this same trick though.
>> 
>> -- - DML
>> 
>> 
> 

- -- 

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

Diaspora:
    nipa at pod.geraspora.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWmPh7AAoJEMo7rS6czNUJjlEQALpFU8HtsO+cJF54sm6K+Xzd
Ki3xBhmPL5nOYWG9p76qqNoYa/Sis/pnn80nD6LWtpEWzPh4acuhvCawmUnaKB7C
ZCeS0iRkiRP+Ih/oqAPrfqkntDmIf/U8kjj+4gWkdK8yPVNwVNZTAaxVrCMQGEnW
dP6/mW98IV2142mzIlennPWutzCNuAV3HbphHRMDLwLKvsfwGhOqhouxOHkDVNL9
EiRV4uvfzeVDGTKt3HKB8fgO3gfzhnKSGZxysodlC/MIHzpz9gyobvMUP5mZcUIn
/0xrb3SWwOM5IuNRQXw5Bb8bXI6w2s73s6afCU75VyXBDXmFDQ/3NORpMhX209Xc
Whv3+UfPx48bv9iu2HMHtixx+uUFbKRSMtSpSBCZi+7yxHwsxmI3vhK7b2i2i9SN
htoqyPq46NnArJzmig7H0MIJrbv9HqZA6Ee9bQk0z91vlQ53wgjHwMFc38AiBewz
ZZUIidWfTOiblcTbGZ9+neURGOb7B3YEdhKnUbf3uLmUnOZvIOeMTCcCxLf6Tm+5
LfykhjacfVWnlWhhMHfRuaAIs3DhbGIPY0QByl1EZBnAzI9l1IemOc6gygsh34Yq
2Elirwh7dbrXMQY5VcJplF2L7lXYI2Jl9yHyLgVe+5+o0WTRTd+4qC45KfJXuLed
kpmOQhsCrLQ76QbdtA5i
=vPnT
-----END PGP SIGNATURE-----