Proposal: #VersionedDependences

[Remi Forax]

I do not like this proposal for several (good) reasons.

The issue asks to be able to store a version strings or a constraints.
It can be interpreted as two different things.
 - the configuration used by example by Maven which uses constraints that will be resolved,
 - the other is the effectively resolved versions which is what this proposal do.
In my opinion, storing the former info maybe more interesting for a language (the actual configuration) than storing the later.

We already agree that we support annotations (and obviously classfile attributes) so any languages are free to store this kind of information in it's own annotation/attribute, which is more flexible.

If we still want to store the version of each requires, i think it's better to store it in a side attribute (an array of versions should be enough) than in the Module attribute, it's more aligned with the way we encode ModuleVersion currently.

The flag --module-version in javac is useless:
 - it's an optional feature that few will use, so runtimes can not use it reliably, so it's as useful as -parameters, 
 - you often need to compile several modules together, if a module A requires a module B and the module B uses a service from module A, but --module-version can only specify one version for all the modules compiled together.

To summarize, i believe that as specified, this feature not useful.

regards,
Rémi

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: jpms-spec-experts at openjdk.java.net
> Envoyé: Vendredi 9 Décembre 2016 22:46:46
> Objet: Proposal: #VersionedDependences

> Issue summary
> -------------
> 
>  #VersionedDependences --- Consider allowing specific version strings,
>  or perhaps version constraints, as an optional element of `requires`
>  clauses in module declarations.  Failing that, consider allowing
>  specific version strings, or perhaps version constraints, to be added
>  to the dependences recorded in a compiled module descriptor; this
>  would, e.g., allow a compiler or build system to record the versions
>  of the modules against which a particular module was compiled, for
>  use by other tools.  In either case, if such version information is
>  merely informative then it will still honor the version selection
>  non-requirement; if such version information is interpreted by the
>  module system then that requirement may come into question. [1]
> 
> 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].
> 
> The specific changes to implement this feature include:
> 
>  - Extend module descriptors to allow the inclusion of version strings
>    in the `requires` table of the `Module` attribute by introducing a
>    `u2 requires_version_index` field after the `requires_flags` field
>    of each entry of that table.  The value of this new field is either
>    zero, to indicate that no version string was recorded, or else the
>    constant-pool index of a `CONSTANT_Utf8_info` structure whose value
>    is the version string.
> 
>  - Extend the `java.lang.module.ModuleDescriptor.Requires` API with a
>    single new method:
> 
>        Optional<ModuleDescriptor.Version> compiledVersion();
> 
>    This method will return an empty `Optional` object if no version
>    string was recorded for the corresponding dependence, or else an
>    `Optional` that contains the recorded version string.
> 
>  - 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.
>    (The RI's `javac` compiler will support this via a new command-line
>    option, `--module-version`.)
> 
>  - 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.
> 
> 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].  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.  The `ModuleDescriptor` API
>    itself will continue to be able to read class files that contain
>    module names that violate this constraint.
> 
> 
> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionedDependences
> [2] http://openjdk.java.net/projects/jigsaw/spec/reqs/#version-selection
> [3] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames
> [4] http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-JavaLetter