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

[Koushik Muthukrishnan Thirupattur]

On Fri, 30 Jan 2026 01:10:41 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> So even if there is a race condition then we'll just insert the same value twice. Would it be possible to insert 2 different values for the same key in this class? It doesn't seem so.

Thanks for the detailed comment. You’re right that this won’t corrupt the cache and that the objects are semantically equivalent. The issue I see isn’t correctness of the cache, but interning/canonicalization semantics.

I think it could be possible for two values to be inserted for the same logical key: if two threads concurrently miss on `get()`, they can both construct separate `X509CertImpl/X509CRLImpl` instances and then both call `put()`. The cache remains valid, but different callers may observe different object instances for the same certificate/CRL. That breaks the intent of `intern()` as documented (returning a canonical cached instance) and can introduce avoidable object churn.

The addIfNotPresent() helper keeps the “check-then-insert and return existing” behavior atomic at this layer, without relying on assumptions about the cache implementation. I would be happy to revisit if we agree interning semantics are not required here. Let me know.

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

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