Module descriptions versus module descriptors

[Paul Benedict]

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