Proposal: #VersionedDependences
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Mon Feb 13 18:21:45 UTC 2017
2017/1/28 4:40:01 -0800, forax at univ-mlv.fr:
> 2017/1/27 17:45:47 -0800, mark.reinhold at oracle.com:
>> ...
>>
>> 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()
Sure, let's go with those. I like that they'll wind up not being nearby
the non-raw methods in the Javadoc, thereby making them less obvious.
- Mark
More information about the jpms-spec-experts
mailing list