Proposal: #VersionedDependences

[David M. Lloyd]

On 01/27/2017 07:45 PM, mark.reinhold at oracle.com wrote:
> 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?

Better than nothing... I'll take it.

-- 
- DML