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