Hi.
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. Cheers Paul On 16 Mar 2020, at 04:32, Xuelei Fan <xuelei....@oracle.com<mailto:xuelei....@oracle.com>> wrote: Hi, 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: https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021421.html Thanks & Regards, Xuelei On 3/12/2020 10:34 AM, Xuelei Fan wrote: And the release note task: https://bugs.openjdk.java.net/browse/JDK-8240968 Xuelei On 3/12/2020 9:47 AM, Xuelei Fan wrote: Hi, 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, Xuelei
