编译大型Java项目class冲突导致报错的解决方案

目录

• 前言
• 查找冲突
• mvn dependency:tree
• 使用第三方工具排查
• bash脚本
• 解决方案
• maven-shade-plugin
• 解压jar包

前言

作为一名合格的JavaBoy，想必大家都遇到过调试大型项目的时候编译完都遇到过一些奇奇怪怪的问题，比如说下面这种。

看起来是一个序列化框架报出来的异常，但是沿着堆栈排查又找不到什么线索，最后把刚开发的模块排除后就会发现这个异常又消失了，代码里并没有用到报错的类，这种情况很有可能遇到了二方库中的类冲突。

本质上就是项目模块太多，依赖错综复杂，新模块引入的二方库中的类与原项目二方库中的类冲突了。可能是原来依赖的版本与新模块中依赖的版本不一致，导致加载类结束后缺少一些类的情况。比较直观的报错有

java.lang.ClassNotFundException
java.lang.NoSuchMethodError
java.lang.NoClassDefFoundError
java.lang.LinkageError

如果直接报出这些异常还有思路去排查，就怕报出一些奇奇怪怪的异常，今天盘点一下遇到类冲突之后如何解决。

编程客栈

查找冲突

mvn dependency:tree

maven提供了一个命令打印项目中所有的依赖树，打印出的消息类似下面的图，从树中可以找到冲突class是来自哪个包哪个模块。增加-Dverbose: verbose参数将详细显示项目所依赖的所有Jar包

但是这样有个致命弱点，就是只能在开发阶段排查，假如编译期间报错还好，如果运行期间加载到某个类出现冲突报错就尴尬了，如果已经打好包在集成环境出现这种问题，这种情况我们就无法通过命令直接去编译源代码查看冲突。

其次就是编译项目太慢了，一个大型项目有几十个模块，编译一次5分钟过去了，虽然可以用着5分钟去掘金摸会鱼，编程客栈但作为一个成熟的JavaBoy摸鱼建立在把手头工作搞好的前提下~

使用第三方工具排查

点名Arthas

bash脚本

这个脚本我屡试不爽，非常好用

#!/bin/bash
# 获取传入的参数
search_directory="$1"
search_class="$2"
android

# 检查参数是否为空
if [ -z "$search_directory" ] || [ -z "$search_class" ]; then
    echo "请提供要搜索的目录和类文件名称作为参数。"
    exit 1
fi


# 搜索指定目录及子目录下的Jar包
find "$search_directory" -name "*.jar" -type f | while read -r jarfile; do
    # 在Jar包中查找包含指定类文件名称的文件
    jar tf "$jarfile" | grep "$search_class" | while read -r classfile; do
 cWHgCcQwTt       # 输出Jar包名称和包含的类文件名称
        echo "Jar包：$jarfile  类文件：$classfile"      
    done
done

shell脚本也很简单，执行下面命令就能找到指定目录下jar包中包含com.esotericsoftware.kryo.io.Input.inputStream类的包，这种方式不仅快而编程客栈且很高效。

sh find_class.sh /tmp com.esotericsoftware.kryo.io.Input.inputStream

解决方案

找到冲突的类只是第一步，如何解决呢，这个问题本质上是项目中出现了不同模块引入了相同的类，如何定义相同得类，java的类加载器认为如果两个class的全限定名完全一样那就是相同的类。那想办法让这俩类的全限定名不一样不就行了。

maven-shade-plugin

maven-shade-plugin是maven的一个插件，配置了这个插件打包的时候会自动触发shade，shade直译为阴影，顾名思义就是帮你把某个class藏起来。

hideOnBush

一般大型项目通常都是用maven来构建项目，比如一个大项目有10个子模块，你添加第11个子模块时候com.google.common类冲突了，那么你在第11个模块中配置如下

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>3.1.0</version>
        <executions>
            <execution>
                <phase>package</phase>
                <goals>
                    <goal>shade</goal>
                </goals>
                <configuration>
                    <relocations>
                        <relocation>
                            <pattern>com.google.common</pattern>
                            <shadedPattern>shade.core.com.google.common</shadedPattern>
                        </relocation>
                    </relocations>
                </configuration>
            </execution>
        </executions>
    </plugin>

这样在编译的过程中com.google.common类会被隐藏为shade.core.com.google.common，全限定名不一样了自然就不会再有冲突了。

解压jar包

还有一种情况是通过引入外部jar包的方式引入依赖，代码已经被打成了jar包，但是jar包里有一些class冲突怎么办呢。

这时候再用maven-shade-plugin也可以，但是一般我们都优先修改外部的代码，不轻易动原有的代码结构，这时候有个骚操作就是解压掉jar包，根据全限定名把冲突的包全删了，再压缩成jar包即可解决。

• 将jar包解压到一个临时文件夹中

unzip a.jar -d /tmp/tmpdir

• 进入文件夹删除掉指定的包路径
• 重新打包jar文件，注意最后有个.

jar cf a-new.jar -C /tmp/tmpdir .

将新的jar包重新加入模块你会发现项目畅通无阻。

到此这篇关于编译大型Java项目class冲突导致报错的解决方案的文章就介绍到这了,更多相关Java class冲突内容请搜索编程客栈(www.devze.com)以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程客栈(www.devze.com)！