On Fri, 30 Jan 2026 17:33:36 GMT, Xue-Lei Andrew Fan <[email protected]> wrote:
>> Yes, I'm actually currently thinking whether to attach this cache to >> SSLContext instance or not. Not sure about it. This cache implementation has >> LRU mechanism, so it will simply keep the last 12 compressed certs in memory >> which should be fine for most scenarios. It's also an easier to maintain >> code where we have all the pieces in a single file. Currently we have only >> session caches attached to SSLContext and quite a few static caches like >> this one in JSSE code. > > I had a quick search of the existing cache. There are some global cache for > default security parameters and configuration. For example, default trust > anchor, default context and default managers. I think it is fine as default > one always use the same configuration and can be shared. > > The compressed certificate cache looks different, as it is not for default > key/cert configuration. Basically, the identity certificate is a property of > key manager. It may be safer to manage the cache in key manager level > instances. Yes, good point, it is different, I've done similar research. I'll look closer into this, thanks! Some problems I can see with this approach though: - Such caching won't work with a 3rd party `X509ExtendedKeyManager` implementations. - `CertificateMessage` is not just a single certificate, it's the list of certificate entries plus certificate_request_context. Logically such cache doesn't belong to a KeyManager. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28682#discussion_r2747427885
