BouncyCastle版本冲突，供应商不合作

Question

目前，由于与BouncyCastle版本冲突，我一直致力于集成Java。

我们在内部开发了一个组件，使用本地税务局提供和维护的官方Java API处理发送给地方税务局(不是“国税局”，而是另一个欧洲国家的同等税务机构)的数据文件。我们平台的另一个模块使用一个来自证书颁发机构的组件来执行文件的认证时间戳。两者都必须集成到部署在客户站点上的单个web应用程序中。

正如您可能知道的，两个包所依赖的BouncyCastle包都经历了几次公共API更改，因此后续版本不再是二进制兼容的。

收入服务提供"cryptotools.jar“包，这取决于以下几点：

<dependency org="org.bouncycastle" name="bcprov-jdk15on" rev="1.49"/>
<dependency org="org.bouncycastle" name="bcpkix-jdk15on" rev="1.49"/>

证书颁发机构提供“jades内核”时间戳包，该包取决于

<dependency org="org.bouncycastle" name="bcmail-jdk15"     rev="1.45"/>
<dependency org="org.bouncycastle" name="bcprov-jdk15"     rev="1.45"/>
<dependency org="org.bouncycastle" name="bcprov-ext-jdk15" rev="1.45"/>
<dependency org="org.bouncycastle" name="bctsp-jdk15"      rev="1.45"/>

在类路径上同时使用这两个包会导致将所有BouncyCastle包转储到我的WEB-INF/lib文件夹中，这听起来并不坏

​

​

但是，如果我尝试使用所有这些包启动web应用程序，我就会得到一个Error，它表示类扩展了最后的方法。我不会发布堆栈跟踪，这与我的问题无关

如果我删除BC的两个版本(1.45或1.49)中的任何一个，其中一个模块将不会编译。嗯，它们都已经编译好了，所以它们不会简单地链接到它们所引用的类/方法。

我已经向CA报告了这种情况(我们与CA签订了Java的维护合同)，使用了较早的BC版本(该版本存在由Black Duck发现的安全漏洞，因此我的客户使我的生活很痛苦)。CA还没有合作。他们需要发布一个新版本的加密API，与更新版本的BouncyCastle兼容。

我和我的老板(C级老板)正在把问题升级到CA等级，并且，根据我们当地的幽默，我们很快就会升级到弗朗西斯。

提到幽默，请允许我以视觉的方式分享我目前的感受。

​

​

提问时间，现在回到严肃的讨论

假设我们的供应商不合作，或者至少没有及时完成我们的监管期限。收入服务不会明显地将他们的Java降级为一个较旧的BC版本。

我们如何摆脱这个依赖地狱?例如，我知道log4j有一个“桥梁”包来减轻那些还没有升级的包在1.x和2.x版本之间的破坏。当两个模块依赖于不同的BC版本时，我们如何使它们共存？

我会发布一个可能的解决办法，但这不是我们喜欢的解决方案。

Answer 1

本质上，Java不是为此而构建的，Maven当然不是这样的(因为在解决这些冲突时，任何较新的版本都是对旧版本的完美替代)。

我的理解是，您有一个单块应用程序，因此由于您不能物理地拆分类路径，所以您可以逻辑地这样做。

处理此问题的一种方法是在多个类加载器中运行应用程序，这样jar文件就不会“触碰”。我在前面问了一个“如何在多个类加载器中运行”的问题-- 想要并行运行非线程安全库-可以使用多个类加载器完成吗？ --这种方法结合加载一个不在类路径上的jar可能是可行的。

Answer 2

解决方法可能是将web应用程序划分为多个应用程序，每个应用程序部署在不同的上下文中，并通过web服务进行通信。次要的应用程序将只是私人的。

时间戳模块将有它的类路径与较早的BC版本，税务服务模块将有一个不同的类路径。“主”前端web应用程序将完全不依赖于BC。

这并不能解决黑鸭问题，因为客户将强制进行升级，或者需要大量的文书工作才能允许策略例外。