Module descriptions versus module descriptors

[Cristiano Mariano]

I am problably being too simplistic, but this statement below, from SOTMS,
makes clear the need for the possibility of declare a version number for
module dependencies, to mantain fidelity across phases:

"Module declarations are part of the Java programming language, rather than
a language or notation of their own, for several reasons. One of the most
important is that module information must be available at both compile time
and run time in order to achieve *fidelity across phases*
<http://openjdk.java.net/projects/jigsaw/spec/reqs/02#fidelity-across-all-phases>
, *i.e.*, to ensure that the compile-time environment of a source file is
identical to the run-time environment of the resulting class file. This, in
turn, allows many kinds of errors to be prevented or, at least, reported
earlier—at compile time—when they are easier to diagnose and repair."

Also, the specification states most application currently "rely" upon the
class path. I dont think this statement would be an excuse to not implement
versions. The class path as it is today is NOT reliable. Otherwise, we
would be talking about class path hell.

"Most applications are not containers and, since they currently rely upon
the class path, do not require the ability to load multiple versions of a
module. Container-type applications can achieve this, when needed, via
dynamic configuration, as outlined above."

I am sure implementing a range version system is not an easy task and we
are already late in Java 9, but why not implement a specific version
declaration now and, maybe in Java 10, implement ranges?

On Tue, Dec 15, 2015 at 6:28 PM, David M. Lloyd <david.lloyd at redhat.com>
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
>>
>>
>>
> --
> - DML
>