[9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)
Wang Weijun
weijun.wang at oracle.com
Fri Jun 24 01:22:09 UTC 2016
- Previous message (by thread): [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)
- Next message (by thread): [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
> 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
- Previous message (by thread): [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)
- Next message (by thread): [9] RFR 8130181: Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the security-dev
mailing list