David M. Lloyd
david.lloyd at redhat.com
Mon Jan 30 15:14:57 UTC 2017
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.
More information about the jpms-spec-observers