SSLContext instances

[Scott Lewis]

Greets,

I'm not a regular participant on this mailing list, so please forgive 
the newby and point me in the right direction if this has already been 
discussed.

I am a regular configurer [1] and consumer of SSLContext [2] 
instances...e.g. for jdk httpsclient config, apache httpsclient config, 
other https impls, custom sslsocketfactory impls, etc.

The SSLContext.getInstance static methods, along with 
SSLContext.getDefault() static method are the way for SSLContext 
instances to be accessed for configuring https/tls.  In many/most of the 
httpsclient impls, SSLContext.getDefault() is frequently/traditionally used.

There is also a method SSLContext.setDefault(SSLContext) [3], whose jdk 
17 implementation has a permission check (setDefaultSSLContext) to 
prevent access to calling setDefault.

With security manager deprecation/removal,  could this create security 
issues for JVM-based environments?    Particularly modular/dynamic 
systems? (e.g. OSGi, JPMS)

Thanks,

Scott

[1] 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLContext.html#init(javax.net.ssl.KeyManager%5B%5D,javax.net.ssl.TrustManager%5B%5D,java.security.SecureRandom)

[2] 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLContext.html

[3] 
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLContext.html#setDefault(javax.net.ssl.SSLContext)