Java含Shaded Jar时类加载机制及Guava版本冲突问题咨询

1. Shaded Jar是否可能引发该异常？ #

是的，但需要明确：真正引发冲突的并非那个已经正确shade的Guava jar，而是nautilus-es2-library-2.3.4.jar。

你列出的三个类中：

• java-driver-shaded-guava里的类路径是com.datastax.oss.driver.shaded.guava.common.base.Suppliers$MemoizingSupplier——这个是被shade工具重命名了包的类，全限定名和标准Guava的com.google.common.base.Suppliers$MemoizingSupplier完全不同，JVM会将其视为独立的类，不会和你依赖的Guava 30.1.1产生冲突。
• nautilus-es2-library-2.3.4.jar里的com.google.common.base.Suppliers$MemoizingSupplier——这个是未被shade的旧版本Guava（18.0）类，和你项目依赖的30.1.1版本的类全限定名完全一致。
• guava-30.1.1-jre.jar里的是你声明依赖的新版本类。

问题出在类加载顺序：Web容器（如Tomcat）的类加载器会按类路径中jar的顺序扫描加载类，哪个jar先被扫描到，就优先加载其中的类。如果生产环境中nautilus-es2-library-2.3.4.jar在guava-30.1.1-jre.jar之前被扫描，旧版本的Suppliers$MemoizingSupplier就会被加载。而Guava 18.0的这个内部类并未实现java.util.function.Supplier（该接口是Java 8引入的，Guava后续版本才让这个类实现它），当代码尝试将旧类实例当作Supplier使用时，就会抛出IncompatibleClassChangeError。

本地无法复现的原因，大概率是本地类路径中jar的扫描顺序和生产环境不同——比如本地Maven依赖顺序里，Guava 30.1.1排在nautilus jar前面，加载的是新版本类，因此无异常。

2. Shaded Jar的类加载机制讲解 #

Shaded Jar的核心作用是通过修改类的全限定名避免类路径冲突，其底层逻辑和类加载机制的关联如下：

• JVM判断两个类是否为同一个类，取决于类的全限定名和加载它的类加载器。Shade工具（如Maven Shade插件）会将目标jar中指定包下的所有类的包名替换为新路径（比如把com.google.common改成com.xxx.shaded.guava）。
• 同时，Shade工具会修改类内部的引用，确保这些类调用的是重命名后的包下的其他类，避免出现找不到类的问题。
• 经过shade处理后，原本相同全限定名的类会变成不同的类，即使同时存在于类路径中，类加载器也会将它们当作独立的类分别加载，不会产生冲突。

临时解决思路 #

• 尝试在Maven依赖中排除nautilus-es2-library的Guava依赖，强制它使用你项目中的30.1.1版本：

<dependency>
    <groupId>[该库的groupId]</groupId>
    <artifactId>nautilus-es2-library</artifactId>
    <version>2.3.4</version>
    <exclusions>
        <exclusion>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
        </exclusion>
    </exclusions>
</dependency>

• 如果排除后war包中仍存在nautilus-es2-library里的com.google.common类，说明该库是直接将Guava类打包进自身jar的，此时需要联系开发者提供shade版本，或自行对该jar进行shade操作，重命名其中的com.google.common包。

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