forax at univ-mlv.fr
forax at univ-mlv.fr
Sat Jan 28 12:40:01 UTC 2017
----- 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?
for the API, if i can nitpick, i prefer:
> - Mark
More information about the jpms-spec-experts