Proposal: #VersionedDependences

[mark.reinhold at oracle.com]

2017/1/27 14:24:21 -0800, mark.reinhold at oracle.com:
> 2017/1/27 9:53:23 -0800, forax at univ-mlv.fr:
>> ...
>> 
>> I see no problem to have the ModuleBuilder to enforce a specific
>> format but a ModuleDescriptor should return an Optional<String> (it
>> can also retruns an Optional<Version> in an overloaded method but it
>> should be possible to get the string version).
>> 
>> Version format depends on the module system, it should be enforced by
>> the code that creates the Layer.
> 
> Yes, the version format depends on the module system, and that module
> system is JPMS.  We're not designing multiple different module systems,
> nor a low-level framework upon which multiple different module systems
> can be implemented.  The JPMS version format attempts to encompass a
> wide variety of existing version schemes, but it does not (and can not)
> encompass them all.

Thinking on this further, perhaps you're right.

It's true that we're designing just one module system here, not many,
but for the sake of tradition and (perhaps needless) generality we've
already accepted that binary module descriptors can define and refer
to modules whose names would not be accepted in a source-form module
declaration.  The `ModuleDescriptor.Builder` API is (more or less)
aligned with the source language, but you can use the various `read`
methods in `ModuleDescriptor` to instantiate instances of that class
that you couldn't construct with the `Builder`.

Allowing non-source-code names to surface in the API is easy, since
they're still just strings.  Versions are trickier, since when they're
actual JPMS versions we'd like to represent them as instances of the
`Version` class, but if they're not JPMS versions then we should still
somehow surface them as strings.

I suppose the best we can do here is, wherever a version is exposed,
define a pair of methods.  One will return the raw version string; the
other will return a `Version` object if the raw string can be parsed
as such, and an empty `Optional<Version>` otherwise.

So instead of the single `compiledVersion` method proposed for the
`Requires` class we'd have two,

    Optional<String> compiledVersionString();
    Optional<ModuleDescriptor.Version> compiledVersion();

and similarly for the `ModuleDescriptor::version()` method itself.

Make sense?

- Mark