RFR: 8371721: Refactor checkTrusted methods in X509TrustManagerImpl [v2]
Sean Coffey
coffeys at openjdk.org
Wed Nov 26 20:26:51 UTC 2025
On Tue, 25 Nov 2025 21:43:55 GMT, Artur Barashev <abarashev at openjdk.org> wrote:
>> The 3 checkTrusted methods in X509TrustManagerImpl have a lot of repeating code that can be moved into a helper method.
>> Also refactoring X509TrustManagerImpl logging code since we are touching this file.
>
> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>
> - Fix merge errors
> - Merge branch 'master' into JDK-8371721
>
> # Conflicts:
> # src/java.base/share/classes/sun/security/ssl/SSLLogger.java
> # src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java
> - 8371721: Refactor checkTrusted methods in X509TrustManagerImpl
src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 101:
> 99: serverValidator = v;
> 100:
> 101: if (SSLLogger.isOn() && SSLLogger.isOn("ssl,trustmanager")) {
One benefit of the older style log call was that we got c2 inlining and some deadcode elimination in various security methods if the SSLLogger was off. i.e. if `SSLLogger.isOn()` was proven to always be false, then c2 could remove such code paths. The new `logFine` type calls bring one extra level of method reference but it might be worth confirming that c2 is able to inline such calls and perform dead code elimination also.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28275#discussion_r2566401620
More information about the security-dev
mailing list