Module descriptions versus module descriptors

[David M. Lloyd]

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

-- 
- DML