On Wed, 26 Nov 2025 15:54:50 GMT, Sean Coffey <[email protected]> wrote:
> Introduce lazy static initialization logic to SSLContextImpl via use of the
> new LazyConstant API and improve logging output
>
> As per JBS comments:
>
> * Each subclass of AbstractTLSContext (TLSv10. TLSv11 etc) is being
> initialization at framework initialization time due to the
> getApplicableSupportedCipherSuites(..) calls made in static block. Such calls
> are unnecessary if the subclass isn't required. This is especially true for
> the default JDK configuration where TLSv10, TLSv11 protocols are disabled.
> I've moved logic to lazy initialization of these fields via LazyConstant
>
> * The debug prints output never made clear what protocol version each cipher
> suite was being disabled for. Improved logging there
> * The debug prints never printed out the resulting set of enabled/allowed
> cipher suites
>
> There's efficiency gain also in having one less call to the
> getApplicableEnabledCipherSuites method in the scenario where customized
> cipher suites are not in use.
>
> example of new debug output:
>
>
> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997
> GMT|SSLContextImpl.java:425|Ignore disabled cipher suites for
> protocols:[TLSv1.3, TLSv1.2]
> [TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384
> TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA
> TLS_RSA_WITH_AES_128_CBC_SHA]
> javax.net.ssl|TRACE|30|main|2025-11-26 14:31:31.997
> GMT|SSLContextImpl.java:425|Available cipher suites for protocols:[TLSv1.3,
> TLSv1.2]
> [TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDHE_E...
src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line 515:
> 513: }
> 514:
> 515: public static String wrapText(String text, int maxWidth) {
This seems like it might be useful outside of `SSLContext`. Do you think it
could be part of `SSLLogger` rather than here? Given that it's static and
visible it can stay where it is, but if other classes within SunJSSE could
benefit from it it feels more natural to belong to the logger class.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28511#discussion_r2565937162
