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