倚天生态迁移-Java业务jar包迁移倚天适配实践总结

迁移原因

有些jar包有jni调用，其调用的so是和处理器架构强相关的，不同处理器架构需要使用不同的so，若jar包没有包含arm64/aarch64处理器架构的so，则在倚天上使用该jar包需要进一步适配增加aarch64的支持。

jar包扫描结果分类

通过Yoda可以扫描jar包检测对倚天的兼容性，具体可以分为以下几种场景：

场景1：兼容aarch64处理器架构，可直接在倚天进行灰度验证，验证完以后可以上生产环境

兼容的原因

a.jar包没有包含jni so二进制，都是class文件

b.jar包包含的jni so二进制包含aarch64/arm64版本，例如：

snappy-java-1.1.2.6.jar/org/xerial/snappy/native/Linux/aarch64/libsnappyjava.so

场景2：jar包引用了开源第三方jar包的so，高版本有兼容aarch64版本可直接升级

升级方法一：修改pom文件，修改版本号重新构建

通过mvn dependency:tree进行检测第三方jar包是直接引用还是间接引用

1.间接引用：

通过exclude标签去除第三方依赖包含的snappy-java，然后在本项目的pom中添加高版本的snappy版本依赖。

2.直接引用：：maven构建项目，则修改pom文件，升级对应依赖jar包的版本，重新构建jar包

<dependency>

 <groupId>org.lz4</groupId>

 <artifactId>lz4-java</artifactId>

 <version>1.4.0</version>

</dependency>5

通过mvn命令重新构建

升级方法二：通过压缩工具解压jar包，然后重新打包（该方法仅使用poc场景验证，生产环境推荐使用方法一）

有些jar包可以直接使用解压缩工具打开；有些jar包用解压缩工具打开后是cpgz文件，此时建议使用unzip命令进行解压。

注意：有些jar包直接替换so会出现jar jni调用失败，主要原因是so源码编译时第三方jar包做了接口名称替换，所以具体jar包需要具体分析。

unzip lz4-java-1.4.0.jar

获取lz4-java的jni包含的so

通过find ./ -name "*.so"获取so路径

find ./ -name "*.so"

利用原有的MANIFEST文件重新打包

jar cvfm lz4-java-1.4.1.jar META-INF/MANIFEST.MF -C net/ .

场景3：jar包引用了开源第三方jar包的so，开源无兼容aarch64版本，则重新编译第三方jar包，导入本地maven仓库

本文以jffi为例编译

步骤一：下载jiffi源码

git clone https://github.com/jnr/jffi.git

步骤二：根据readme编译软件

mvn package install

包含so的jar包已编译完成并安装到

/root/.m2/repository/com/github/jnr/jffi/1.3.11-SNAPSHOT/jffi-1.3.11-SNAPSHOT-native.jar

步骤四：查看是否编译生成so

步骤五：导入编译完成的jffi-native的jar包

若本机重编UDF文件，则不需要导入上述编译完成的jffi-native的jar包，若其他机器编译则需要在对应的编译机器上创建/root/.m2/repository/com/github/jnr/jffi/1.3.11-SNAPSHOT/目录

mkdir -p /root/.m2/repository/com/github/jnr/jffi/1.3.11-SNAPSHOT/

将jffi-1.3.11-SNAPSHOT-native.jar、jffi-1.3.11-SNAPSHOT.jar、jffi-1.3.11-SNAPSHOT-complete.jar和pom文件拷贝到上述目录

步骤六：Maven构建的pom文件

<groupId>com.github.jnr</groupId>

<artifactId>jffi</artifactId>

<version>1.3.11-SNAPSHOT</version>

<name>jffi</name>

重新编译构建