RFR JDK-8227024 : Remove the deprecated javax.security.cert APIs

Paul Stanley pj.stanley at live.co.uk
Mon Mar 16 08:31:27 UTC 2020


I believe that you should remove deprecated javax api's. By delaying it, you are pushing the problem into 2022.

If they are removed now then it will force developers to use the correct crypto api's, rather than using a mixture which is what's currently happening.

The compatibility problem for historic code can fixed by an optional 3rd party library/module.



On 16 Mar 2020, at 04:32, Xuelei Fan <xuelei.fan at oracle.com<mailto:xuelei.fan at oracle.com>> wrote:


Thank you all for the review.

This is a note to cancel this update. During the review,  we got
concerns about the compatibility impact about the removal of the
interface method (SSLSession.getPeerCertificateChain()).  Maybe, I
should move forward to resolve the concern first, and then come back for
the removal in a few years.

For more details, please refer to the new code review request:

Thanks & Regards,

On 3/12/2020 10:34 AM, Xuelei Fan wrote:
 And the release note task:


 On 3/12/2020 9:47 AM, Xuelei Fan wrote:

 Could I get the following update reviewed?

 CSR: https://bugs.openjdk.java.net/browse/JDK-8227395
 Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/

 The legacy javax.security.cert APIs and the dependent were initially
 deprecated in Java SE 9 and marked for removal in Java SE 13.
 Applications should use the java.security.cert APIs for now.  This is
 a request to remove the deprecated javax.security.cert APIs.

 The use of the legacy APIs should be rare now.  But please let me know
 if you have concerns before March 19, 2019.

 Thanks & Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20200316/5ac10538/attachment.htm>

More information about the security-dev mailing list