我创建了一个Java应用程序，需要将其分发给安装了JRE的大量用户，但大多数用户的JRE中都没有JCR Unlimited Strength Policy jar文件（因为这些文件需要放入其中）手动并且不与JRE安装捆绑在一起。）
现在，我已经在几个地方读到，由于许可限制，JCE文件无法与需要部署的应用程序捆绑在一起，必须手动下载并放入JRE。这是真的？如果是这样，我是否无法运送这些文件！这样做的另一个问题是跟踪JRE版本 - 因为不同版本的JRE有不同的JCE jar。所以我可能需要为JRE 1.4到1.7捆绑JCE jar（这是我的应用支持）。
是否有JCE无限强度政策文件的替代方案？ BountyCastle还需要这些文件。 我对这些文件做的唯一事情是AES256加密。任何替代方案都会有所帮助。
由于
答案 0 :(得分：3)
Bouncy Castle 提供程序需要这些文件，并且仅适用于使用这些策略文件的JRE（但由于这是Oracle，我猜你会被困住）。
在绝望的时候，您可能希望使用Bouncy Castle轻量级API（以org.bouncycastle开头的类）进行加密。当然缺点是需要重写，API不太好。轻量级API也不能用于插入更高级别协议（如JSSE（SSL）和CMS）的实现。
或者，最后，您可以保持在限制规则的范围内。 AES-128是非常强大的东西（实际上，您可能想知道在实际应用中将AES-128部署在AES-258上时的区别是什么。）
答案 1 :(得分：1)
这些文件是必需的，以便在您的程序中进行高于某些国家/地区的进口法律允许的加密。
默认情况下，jre不带有无限制的策略，但根据国家/地区的政策，它是单独的下载。
这样做的另一个问题是跟踪JRE版本 - 如 不同版本的JRE有不同的JCE罐子。所以我可能会 必须捆绑JRE 1.4到1.7的JCE罐子（这是我的应用程序 支持）。
你不需要这样做。在他的机器上安装jre的用户也将安装相应的文件，使用JCA / JCE或JSSE的代码不应受到影响。
现在我不知道你的应用程序有什么许可问题来预先配置你需要在目标系统中运行的所有jre，如果它是一个有效的替代