[9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)

[Weijun Wang]

Yes, this is precise.

I have no other comment.

Thanks
Max

On 7/8/2016 10:24, Valerie Peng wrote:
>
> Hmm, as I re-read it, I think it's too ambiguous to include '.' as a
> separator as it's possible to interpret the info as optional trailing
> info instead of version number as your earlier comment mentioned.
> I updated the @implNote and removed the '.' as the separator for the
> other info. I think this one should be clearer...
> Webrev is updated in place with only Provider.java, i.e. see line
> 233-248 of
> http://cr.openjdk.java.net/~valeriep/8130181/webrev.02/src/java.base/share/classes/java/security/Provider.java.sdiff.html
>
>
> (Will update CCC after webrev is finalized)
> Thanks,
> Valerie
>
> On 6/30/2016 7:18 PM, Wang Weijun wrote:
>> One tiny thing, in Provider.java:
>>
>>   244      *{@code getVersion()}, by filtering out the trailing
>> optional information
>>
>> There should be a space between * and {.
>>
>> I am not sure if this is worth a clarification, that when version
>> string is "1.2.3", we would like "1.2" being the version number and
>> "3" being other information. Do you think your @implNote also allows
>> "1" being interpreted as version number and "2.3" as other
>> information? A regex is greedy but the @implNote does not imply it.
>>
>> --Max
>>
>>> On Jul 1, 2016, at 9:12 AM, Valerie Peng <valerie.peng at oracle.com>
>>> wrote:
>>>
>>>
>>> Webrev updated with your suggestion:
>>> http://cr.openjdk.java.net/~valeriep/8130181/webrev.02/
>>> Thanks,
>>> Valerie
>>>
>>>
>>> On 6/24/2016 5:05 PM, Wang Weijun wrote:
>>>>> On Jun 25, 2016, at 7:50 AM, Valerie Peng <valerie.peng at oracle.com>
>>>>> wrote:
>>>>>
>>>>> I thought about it, but as Provider object is serializable, if the
>>>>> field is of new type Runtime.Version class, the (de-)serialization
>>>>> against older releases may break.
>>>> I see.
>>>>
>>>>> What exactly is the version style that you have in mind then? I
>>>>> think the major.minor thing is quite reasonable.
>>>>> 1.9d does not really look like a version to me. Do you want to
>>>>> special handling this just because the earlier version is a double?
>>>> Since you mentioned "major" and "minor" in the spec, we have to
>>>> define it. Either referring to the Version class, or define one
>>>> inside Provider. My preference is later, with a regex
>>>> /(^\d+(\.\d+)?)/, which is a superset of Version.
>>>>
>>>> --Max
>>>>
>>>>> Valerie
>>>>>
>>>>> On 6/23/2016 6:59 PM, Wang Weijun wrote:
>>>>>> If you mandate the use of Verona version style, can we just use
>>>>>> the Version class in the constructor?
>>>>>>
>>>>>>> On Jun 24, 2016, at 9:56 AM, Valerie Peng
>>>>>>> <valerie.peng at oracle.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Well, we have to define something for the version syntax and how
>>>>>>> it converts to the legacy double version.
>>>>>>> I think it makes sense to follow the Verona JEP as that's the JDK
>>>>>>> version syntax which seems to fit the normal convention of
>>>>>>> release numbering.
>>>>>>>
>>>>>>> Maybe we can clarify major and minor by referring to
>>>>>>> java.lang.Runtime.Version class?
>>>>>>> Valerie
>