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

[Valerie Peng]

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

On 6/23/2016 6:22 PM, Wang Weijun wrote:
>> On Jun 24, 2016, at 9:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>>
>> I am not sure if we can always return 0d for getVersion() even if we deprecate this method.
>> Doubt that people are relying on this, but don't we normally keep the functionality the same after deprecating a method?
> I accept this.
>
>> "9.0d" is not the supported version format. The new version string syntax follows what's suggested in Verona JEP, not the the direct string representation of double. 9.0d is only for specifying double value in the older constructor. I don't think it means you can call the new constructor by just adding a quote around it to convert it into a String.
>> Maybe we need to document it somewhere to prevent this potential user error?
> Yes.
>
> In the new Provider constructor, you mentioned
>
>   233      * @implNote The JDK implementation will process the specified version
>   234      * string by keeping only the major and minor versions and then
>   235      * convert the result into a double for {@code getVersion()}. If parsing
>   236      * failed, value 0 will be returned.
>
> but the meaning of "major and minor versions" is actually undefined. Do we really require a 3rd party vendor to use the Verona version style?
>
> Thanks
> Max
>