判断WAR包中依赖b的加载版本及移除uberjar嵌入依赖的方法

一、能否静态确定运行时加载哪个版本的依赖b？ #

无法仅通过检查WAR包（包括读取字节码）确定运行时会加载旧版漏洞b还是新版安全b，最终结果取决于运行时的类加载策略等外部因素，原因如下：

• 不同应用服务器的类加载规则有差异：比如Tomcat的WebappClassLoader优先加载WEB-INF/classes，再加载WEB-INF/lib，但对于嵌套在uberjar里的类，部分服务器的加载逻辑和直接放在WEB-INF/lib的JAR不同，静态检查无法覆盖所有服务器的规则。
• 自定义类加载器的影响：如果应用或依赖a中存在自定义类加载器，会直接改变类的搜索顺序，这类动态逻辑无法通过静态文件分析识别。
• 类加载的路径优先级：即使类全限定名一致，类加载器会按照自身的搜索路径决定先加载哪一份类文件，而这个路径的具体规则无法仅通过WAR包的文件结构完全确定。

二、移除UberJar a中嵌入的依赖b的推荐流程 #

不一定需要从源码重新构建a，推荐按以下步骤操作：

1. 解压目标UberJar：执行命令 jar xf a.jar，将a的所有内容解压到一个临时目录。
2. 清理嵌入的b的内容：
   • 在解压目录中找到b对应的包路径（例如com/fasterxml/jackson/core），直接删除整个包目录。
   • 检查META-INF目录下的依赖清单文件（如MANIFEST.MF、依赖索引文件），如果有记录b的条目，一并删除。
3. 重新打包JAR：执行命令 jar cf a-modified.jar -C 临时解压目录/ .，将修改后的文件重新打包成新的JAR。
4. 验证修改结果：
   • 用jar tf a-modified.jar命令确认b的类文件已完全移除。
   • 可通过字节码工具（如javap）检查a中的类是否仍能正常引用b的公开接口，确保新版b能满足依赖需求。
5. 替换WAR包中的原JAR：将修改后的a-modified.jar替换WAR包内WEB-INF/lib下的原a.jar，重新打包WAR包即可。

如果静态修改后出现类引用错误（比如a依赖了b的内部非公开API），则需要从源码重新构建a：

• 拉取a对应版本的源码，修改构建配置（如Maven的pom.xml或Gradle的build.gradle），排除对b的依赖，将b的依赖范围设置为provided（让运行时使用外部的新版b）。
• 重新构建得到不包含b的a.jar，再替换到WAR包中。

内容的提问来源于stack exchange，提问作者Z.T.