Different way to solve 8241047

[Philippe Marschall]

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