Sun 为加密算法制定标准名称而不是命名常量的决定背后是否有理由?
似乎 Sun(好吧,现在是 Oracle)在记录算法名称方面做出了明确的努力,但没有在库中提供强定义的命名常量。我知道,从跨平台的角度来看,字符串搜索方法是有利的。
但是,这样做意味着程序错误会延迟到运行时,我只能看到这使事情变得比必要的更困难。为什么是这样?
Sun 为加密算法制定标准名称而不是命名常量的决定背后是否有理由?
似乎 Sun(好吧,现在是 Oracle)在记录算法名称方面做出了明确的努力,但没有在库中提供强定义的命名常量。我知道,从跨平台的角度来看,字符串搜索方法是有利的。
但是,这样做意味着程序错误会延迟到运行时,我只能看到这使事情变得比必要的更困难。为什么是这样?
String
eg中使用的不Cipher.getInstance(String algorithm)
包含单个名称,它也包含转换。在密码反馈模式下,您会有类似"DES/CFB8/NoPadding"
DES 算法的指示,8 位输出不需要填充。这种组合也可以用于其他密码。所以这已经产生了许多等于 的常数cipher * modes * bitsizes * paddingmodes
。现在您可以创建单独的枚举,但您已经可以看到它会从哪里开始受到伤害。
字符串比枚举或(甚至不去那里)常量灵活得多。这使得添加其他算法变得非常容易。您甚至可以添加算法并在旧软件中配置它们;只需添加一个实现给定算法的提供程序。在从提供者和服务构建的动态框架中使用时,这一点非常重要。
Cipher
正如 Luiggi 所指出的,创建一个接受枚举并返回一个或Signature
实例的工厂将非常容易。您只需对工厂进行一次测试。
我想这将允许您提出自己的非标准名称和工厂实现。(或者允许将来的插件使用尚不存在的名称)而不会导致编译错误。
这也将允许用户通过将类添加到编译时未知的类路径来在运行时添加新的加密类。