Proposal: #VersionedDependences

[David M. Lloyd]

Inline...

On 12/09/2016 03:46 PM, mark.reinhold at oracle.com wrote:
> Issue summary
> -------------
> [...]
>
> Proposal
> --------
>
> When compiling a module that depends on some other modules, record the
> version strings of those modules, if available, in the resulting module
> descriptor.  These version strings will not be interpreted, in any phase;
> they are provided solely for diagnostic purposes and for use by tools,
> frameworks, and containers that assist in the selection and validation
> of module versions.  This proposal, therefore, continues to honor the
> version-selection non-requirement [2].

I can see this being very useful.

> The specific changes to implement this feature include:
>
>   - Extend module descriptors to allow the inclusion of version strings
> [...]
>   - Extend the `java.lang.module.ModuleDescriptor.Requires` API with a
>     single new method:
> [...]
>   - Recommend that Java language compilers provide a means by which a
>     version string can be indicated for any modules being compiled, and
>     that they record such strings in the resulting module descriptors.

Great, this will be very useful.

>   - If a compiler can record the version string of the modules being
>     compiled in the resulting compiled module descriptors then it would
>     be simpler for those version strings to be placed in the `Module`
>     attribute rather than the ancillary `ModuleVersion` attribute.  We'll
>     therefore drop the latter and add a `u2 module_version_index` field
>     to the `Module` attribute, immediately following the `module_flags`
>     field.

OK

> Now that compile-time versions can be recorded in module descriptors
> there is even less need to tolerate version information in module names,
> a bad practice that we'd like to discourage at the outset.  We therefore
> further propose to:
>
>   - Revise the accepted proposal for #VersionsInModuleNames [3] to state
>     that a module name appearing anywhere in a source-form module
>     declaration must both start and end with "Java letters" [4].

Can we just drop this part?  I really am not a fan of the 
social-enforcement-in-technical-code thing, and I can already think of 
one existing project off the top of my head that will suffer 
collaterally from this: Fabric8.  Also any other project to which the 
"vanity license plate effect" would apply.  And I can think of many ways 
to circumvent this rule, including, but not limited to, bracketing with 
letters "v5slot", roman numerals, etc., so really all it does is add an 
annoying "big brother" effect without practical benefit.

Anyway I disagree pretty strongly that versions (or more specifically, 
version segments) in module names are that really that strong of an 
anti-pattern.  Sure having whole version numbers in is a pretty fragile 
technique, but it's very useful to have (for example) multiple major 
versions of a library on a large distribution to ease migration, 
especially when you're talking hundreds or thousands of modules.

>     This
>     includes the name of the module being declared and also the names of
>     other modules mentioned in `requires` directives or in qualified
>     `exports` or `opens` directives.  This restriction will be enforced
>     by the `ModuleDescriptor.Builder` API, which is intended to be
>     consistent with the source language.

See other email ("whoops...") on this bit.  It would be good to have 
*some* way to programmatically establish modules without having to 
generate bytecode.

-- 
- DML