On 05.10.21 16:27, Sean Mullan wrote:
Hi Philippe, ... The method in question has not been removed from 17 so their code should continue to work as long as the deprecated methods continue to be overridden. It's unfortunate that the 3rd party library cannot be changed - is it active?
It's the client library of a widely deployed middleware from a well known vendor. The client library does not implement SSLSession but ends up calling #getPeerCertificateChain through the default socket factory. Sometimes it would be fun to to back to uni and write a software that scans the whole of Maven Central for callers of particular methods.
The SSLSession.getPeerCertificateChain() has been deprecated since Java 9 and marked for removal since Java 13, and there has been a replacement API available SSLSession.getPeerCertificates() since Java 1.4. That's a lot of time to migrate.
It wasn't enough time for this particular vendor.
... It is an interesting suggestion and I can see your point. I don't think there is any fundamental reason we could not change the default implementation of the SSLSession.getPeerCertificateChain() method, but since it would be a change to the specification, it could not be backported to 17.
That's more or less what I expected but I thought I had to ask. I think we should be able to work around it by making the client library use a custom socket factory.
Also, these methods are marked for removal, so changing the default implementation at this point probably doesn't add much value.
It would allow people who rely on third party dependencies that call #getPeerCertificateChain to migrate to JDK 21, assuming it won't be removed until then. If the types and package are removed by JDK 21 then indeed it wouldn't add much value. Cheers Philippe
