SSLSocketFactory提供getDefaultCipherSuites(套接字上默认启用的密码)和getSupportedCipherSuites(如果需要，可以启用密码)。
但是，SSLSocketFactory不提供setEnabledCipherSuites来配置密码列表一次以在后续套接字上提供优先级。
实际上，我认为使setEnabledCipherSuites成为SSLSocket的一部分确实使炒锅流程复杂化。例如，HttpsURLConnection不提供getSocket，它确实破坏了此流程:
...
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, trustManager.getTrustManagers(), null);
HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
connection.setSSLSocketFactory(context.getSocketFactory());
我认为
SSLContext可以说相同，因为它具有getDefaultSSLParameters和getSupportedSSLParameters之类的方法。我正在尝试提出一个(不可)能力的合理的安全工程理由，但是我不能。决定可能是由软件工程原因造成的。 (我怀疑这是有充分理由的，目前我缺乏见识的见识)。
为什么Java缺乏配置
SSLSocketFactory的能力？这显然是一项设计决定，我正在尝试理解为什么在库的相关部分中以牺牲安全性为代价来做出该决定。 最佳答案
允许应用程序更改已启用的密码套件可能被认为是一个坏主意。您可能会争辩说这是平台安全问题，而不是应用程序责任，并且对于某些应用程序来说，启用(或禁用)系统管理员已禁用/启用的套件将是一件坏事。
但是我不知道，我怀疑真正了解的一小部分人不会定期阅读StackOverflow。
从某种意义上说是的。但这可能只是偶然或默认情况下发生的那些设计决策之一。或者可能是“他们”不认为将使用此功能。或者这样做可能有充分的安全原因。
无论哪种方式，如果您对此有强烈的兴趣，都可以将其建议为Java增强功能(例如here)，或者设计一个实现增强功能的补丁并将其提交给OpenJDK团队。
而且，如果您不愿意提出/实现增强功能，那么回答“他们为什么这样做”的最佳方法是亲自问“他们”。 (并分享答案...)