JDK-8130181 : Deprecate java.security.Provider(String, double, String), add Provider(String, String, String)
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-30
  • Updated: 2022-02-09
  • Resolved: 2016-08-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b133Fixed
Related Reports
Relates :  
JDK-8164456 - JDK 9 builds failed since change of JDK-8130181
Relates :  
JDK-8061493 - JEP 223: New Version-String Scheme
Relates :  
JDK-8130288 - java.security.Provider implementations should use gensrc mechnism
Description
In JEP 223 for JDK 9 (http://openjdk.java.net/jeps/223), versions are defined to be "a non-empty sequence of non-negative integer numerals without leading or trailing zeros, separated by period characters (U+002E)".  A String rather than a double is a more suitable representation.

In JDK 9, deprecate:

  Provider(String name, double version, String info)

Add:

  Provider(String name, String version, String info)

Careful thought is necessary to find a suitable mapping from String to double so that this method continues to be useful:

  public double getVersion()
Comments
Existing regression tests are updated to call the new Provider constructor. So, no new test for this particular change.
03-01-2017
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6c96af8a34b2 User: lana Date: 2016-08-24 21:12:56 +0000
24-08-2016
URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6c96af8a34b2 User: valeriep Date: 2016-08-19 06:34:11 +0000
19-08-2016
The peer review took longer than expected and it's possible for CCC to have some comments too. Current deadline does not allow enough time and we would like to request another 2 weeks to wrap this up. May we request to push out the due date out a bit to 08/5/2016?
15-07-2016
FC Extension Request: Webrev is out for peer review and CCC has been submitted. Risk Level: low, proposed new API to replace the old one which will be deprecated. Justification: related to Verona, make Provider versioning consistent to the same scheme proposed under Verona. Complete Date: see the above Due (currently, 7/16)
21-06-2016