java-BouncyCastle版本冲突,供应商不合作

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

如您所知,这两个软件包所依赖的BouncyCastle软件包已经进行了几次公共API更改,因此后续版本不再与二进制兼容.

Revenue Service提供了“ cryptotools.jar”软件包,具体取决于以下内容：

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

认证中心提供的“ jades-kernel”时间戳包取决于

<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"/>

将两个软件包都放在classpath上会导致所有BouncyCastle软件包都被转储到我的WEB-INF / lib文件夹中,通常听起来不错

但是,如果我尝试使用所有这些程序包启动Web应用程序,则会收到一条错误消息,提示类扩展了最终方法.我不会发布堆栈跟踪信息,这与我的问题无关

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

我已经使用较旧的BC版本(具有Black Duck发现的安全漏洞,向客户报告了这种情况)(与Java签订了维护API的维护合同),从而使我的客户痛苦不堪. CA尚未​​合作.他们将需要发行与较新版本的BouncyCastle兼容的加密API的新版本.

我和我的上司(C级上司)将问题升级到CA层次结构,根据我们的本地幽默,很快我们将升级到Francis

提及幽默,请允许我以视觉方式分享我当前的感受

提问时间,现在回到认真的讨论

假设我们的供应商不配合,或者至少在我们的监管期限内不及时. Revenue Service不会明显将其Java API降级为较早的BC版本.

我们如何摆脱这种依赖地狱？我知道,例如,log4j有一个“桥接”程序包,以减轻那些尚未升级的包在1.x和2.x版本之间的API更改中断.当两个模块依赖于不同的BC版本时,如何使它们共存？

我将发布一个可能的解决方法,但这不是我们的首选解决方案.

据我了解,您拥有一个整体应用程序,因此,由于无法物理上拆分类路径,因此可以在逻辑上进行操作.

解决此问题的一种方法可能是在多个类加载器中运行您的应用程序,以使jar文件不会“接触”.之前我问过一个“如何在多个类加载器中运行”的问题-Want to run non-threadsafe library in parallel – can it be done using multiple classloaders?-这种方法与加载不在类路径上的jar结合起来是可行的.