java - 为什么某些 API(如 JCE、JSSE 等)通过单例映射提供可配置属性？

Question

例如:

Security.setProperty("ocsp.enable", "true");

并且仅当使用 CertPathValidator 时才使用它。我看到两种增强选项:

• 还是单例，但每个属性都有 getter 和 setter
• 包含与当前上下文相关的属性的对象:CertPathValidator.setValidatorProperties(..) (它已经有一个 PKIXParameters 的 setter ，这是一个好的开始，但它并不包含所有内容)

一些原因可能是:

• 从命令行设置属性 - 从命令行到上面建议的类中的默认值的简单转换器将是微不足道的
• 允许不同提供者提供额外的自定义属性 - 他们可以使用public Map getProviderProperties()，甚至可以使用public Object ..进行强制转换。

我很好奇，因为这些属性并不总是在最明显的地方，并且在使用 API 时无法看到它们，您必须在(如果幸运的话)获取它们之前查看数十个谷歌结果。因为 - 首先 - 你并不总是知道你到底在寻找什么。

我刚刚观察到的另一个致命缺点是这不是线程安全的。例如，如果两个线程想要通过 ocsp 检查撤销，它们必须设置 ocsp.responderURL 属性......并且可能覆盖彼此的设置。

Answer 1

这实际上是一个很好的问题，它迫使您思考过去可能做出的设计决策。感谢您提出了一个我几年前就应该想到的问题!

听起来反对意见并不是单例方面(尽管对此可能会发生完全不同的讨论) - 而是字符串键的使用。

我曾经研究过使用这种方案的 API，并且您上面概述的原因绝对是驱动因素 - 它使解析命令行或属性文件变得非常简单，并且它允许第 3 方可扩展性，而无需对官方API的影响。

在我们的库中，我们实际上有一个类，其中每个官方参数都有一堆静态最终字符串条目。这给了我们两全其美的好处——开发人员仍然可以在有意义的地方使用代码完成。还可以使用内部类构建相关设置的层次结构。

尽管如此，我认为第一个原因(易于解析命令行)并不能真正解决问题。创建一个反射驱动机制将设置推送到一堆 setter 中将相当容易，并且它将防止字符串->对象转换的麻烦转移到主应用程序类中。

可扩展性有点棘手，但我认为它仍然可以使用反射驱动系统来处理。这个想法是让主配置对象(其中包含所有 setter 的对象)也有一个 registerExtensionConfiguration(xxx) 方法。标准符号(可能是点分隔)可用于深入研究配置对象的结果非循环图，以确定应在何处调用 setter。

上述方法的优点是它将所有命令行参数/属性文件解析异常处理放在一个位置。不存在格式错误的论点在受到攻击之前流传数周的风险。