From nipa at codefx.org Fri Jan 15 13:47:40 2016 From: nipa at codefx.org (Nicolai Parlog) Date: Fri, 15 Jan 2016 14:47:40 +0100 Subject: Module descriptions versus module descriptors In-Reply-To: <567077EE.8090106@redhat.com> References: <5626CDF7.5060605@redhat.com> <20151210012645.EDDB1849E4@eggemoggin.niobe.net> <5669940E.60902@redhat.com> <56705E61.9060203@redhat.com> <56706892.7090508@redhat.com> <567077EE.8090106@redhat.com> Message-ID: <5698F87C.6000108@codefx.org> -----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 >> > wrote: >> >> On 12/15/2015 12:53 PM, Paul Benedict wrote: >> >> On Tue, Dec 15, 2015 at 12:39 PM, David M. Lloyd >> >> >> >> 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-----