Proposal: #VersionedDependences

[forax at univ-mlv.fr]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: forax at univ-mlv.fr
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Samedi 28 Janvier 2017 02:45:47
> Objet: Re: Proposal: #VersionedDependences

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

yes !

for the API, if i can nitpick, i prefer:
  Optional<String> rawCompiledVersion()
  Optional<ModuleDescriptor.Version> compiledVersion()

> 
> - Mark

Rémi