RFR: 8345954: Revisit Class Initializers and Locking in X509TrustManagerImpl [v3]

[Artur Barashev]

On Thu, 29 Jan 2026 22:48:23 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
>> 
>> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345954: Removing synchronization on getfromcache

Yes, basically I see 2 options:

1. If the intent is to implement a true `intern` method (same as `String.intern()`), where `s.intern() == t.intern()` is true if and only if `s.equals(t)` is true, then I would use `ConcurrentHashMap` which is a hard cache with a fine per-bucket locking. Particularly `computeIfAbsent` method performs get/put operation atomically.
2. If the intent is to return objects that can be compared with `equals()` method and not `==` operator, then we can keep current soft cache implementation and remove all the synchronization. I've done a quick research and I could find a single place in code where we compare certificates or CRLs by reference (with `==` operator), so I suspect that was the original intent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3835248021