开发工具区分普通JAR与Uber-JAR：寻求可靠启发式方法

针对你提到的现有根目录检查方法误判问题（比如junit:junit:4.13.1、logback-classic:1.1.3这类多包普通JAR被误判），可以通过以下多维度启发式组合来提升准确性：

1. 结合META-INF元数据验证依赖范围 #

• 读取META-INF/maven/${groupId}/${artifactId}/pom.xml：
  • 普通JAR的pom.xml只会声明自身的代码结构，依赖项仅作为外部引用存在；如果JAR中包含了pom.xml里标记为compile/runtime的依赖类文件，说明是Uber-JAR。
  • 检查META-INF/maven目录下的子文件夹数量：普通JAR通常只有一组groupId/artifactId文件夹，而Uber-JAR会包含多个不同第三方库的maven元数据文件夹。
• 查看MANIFEST.MF：部分Uber-JAR（如Spring Boot胖JAR）会包含Start-Class、Spring-Boot-Version等特有属性，可作为辅助判断依据。

2. 包名与项目坐标的匹配校验 #

• 从JAR文件名或maven元数据提取项目的主包前缀（比如junit:junit对应junit.和org.junit.，这两个均为JUnit官方包）；
• 统计根目录下所有顶级包：
  • 若所有顶级包均属于项目自身的合法前缀范围，判定为普通JAR；
  • 若存在与项目前缀无关的第三方包（比如Uber-JAR中出现com.google.guava、org.apache.commons等），判定为Uber-JAR。

3. 校验class文件的签名一致性 #

• 使用jarsigner -verify -verbose <jar-file>命令检查class文件的签名：
  • 普通JAR内的class文件通常使用同一签名（或无签名但来自同一项目）；
  • Uber-JAR会包含多个不同签名的class（来自不同依赖库），甚至混合签名与未签名的文件。

4. 基于文件规模的辅助判断 #

• Uber-JAR的体积和class文件数量远大于普通JAR：
  • 比如junit:junit:4.13.1仅有约300个class，而包含hamcrest依赖的Uber-JAR会超过500个class；
  • 可以针对不同类型的库设置动态阈值（比如超过常规普通JAR体积的2倍+class数量翻倍），结合其他特征辅助判断。

5. 改进原有根目录检查逻辑 #

• 对原有方法做精细化调整：
  1. 先通过元数据确定项目的所有合法包前缀；
  2. 过滤掉属于项目自身的多包结构（比如junit的junit/和org/junit/）；
  3. 仅统计不属于项目前缀的顶级包数量，若数量≥1且对应第三方库，则判定为Uber-JAR。

内容的提问来源于stack exchange，提问作者Cornul11