Elastic Compute Service:Migrate Java applications from x86 platforms to YiTian ECS instances

Background information

Java applications use Java dependencies and Java Native Interface (JNI) to call native libraries that are compiled in the C language. If you directly migrate Java applications, compatibility issues may occur. In this case, you can use the following methods to resolve compatibility issues:

• Upgrade the required dependencies if Java dependencies of the applications are incompatible with the Advanced RISC Machine (ARM) platform.

• Rebuild Java projects to resolve issues that occur on the native library of the applications.

Select a JDK

Arm is a new architecture on the server side and widely used in multiple fields. A suitable Java Development Kit (JDK) can help reduce the probability of issues and improve performance. We recommend that you use the following types of OpenJDK on YiTian ECS instances:

• Alibaba Dragonwell: an open source version of OpenJDK developed by Alibaba. Alibaba Dragonwell helps improve the stability, efficiency, and performance of large-scale Java applications that are deployed in data centers. For more information, see Alibaba Dragonwell.

• Eclipse Temurin: an open source Java SE build based on OpenJDK. Eclipse Temurin is compatible with multiple platforms and Java SE versions. For more information, see Eclipse Temurin.

Upgrade the required dependencies

Some Java dependencies are incompatible with Arm. If an error similar to the following errors is reported when you run an application, a compatibility issue occurs on the Arm platform because x86 native libraries are used. You can upgrade dependencies to resolve the issue.

Exception in thread "main" java.lang.UnsatisfiedLinkError: xxx.so: xxx.so: 
cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64-bit .so on a AARCH64-bit platform)

• Scanning for incompatible dependencies

  You can scan SO files for incompatible dependencies. If only SO files for the x86 architecture are included in the scan result, the SO files may not support Arm.

  The following sample code provides an example of the script that is used to scan SO files. You can save the scan script to the compiled application directory and run the script to scan SO files.

  Warning

  To prevent issues, do not use the script in the production environment.

  #!/bin/bash
  rm -rf tmp
  mkdir tmp
  for jar in `find . -name *.jar`
  do
  if [ -f $jar ]
  then
  echo $jar
  cp -r $jar tmp/
  fi
  done
  cd tmp
  for test in `ls`
  do
  name=`echo $test | sed "s/.jar//g"`
  echo $name
  mkdir $name
  cp -r $test $name
  cd $name
  unzip -o $test
  cd ..
  done
  echo "========= starting Analysis =========="
  find . -name "*.so" -exec file {} \;

  After the scan is complete, an output similar to the following one is returned. lz4-1.3.0 contains three SO files of the x86 architecture that do not support the Arm architecture. You can upgrade lz4-1.3.0 to 1.4.0 to resolve this issue.

  lz4 is renamed as lz4-java in 1.4.0 and later versions.

  ========= starting Analysis ==========
  ./lz4-1.3.0/win32/amd64/liblz4-java.so: PE32+ executable (DLL) (console) x86-64, for MS Windows
  ./lz4-1.3.0/linux/amd64/liblz4-java.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2eafd0d4e86904e188b47565639318325108fffa, not stripped
  ./lz4-1.3.0/linux/i386/liblz4-java.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=41041674439aea5d1fd6c62b6d88f63da7600c9f, not stripped

• Common dependencies that may have compatibility issues

  The following table describes the common dependencies that may have compatibility issues. We recommend that you upgrade the dependencies to the recommended versions.

  Dependency name	Recommended version
  lz4-java	1.4.0
  jna	5.2.2
  snappy-java	1.1.3
  icu4j	68.1
  sqlite-jdbc	3.20.0
  forest-sqlite-jdbc	3.32.3.3
  netty-tcnative	2.0.31
  netty-transport-native-epoll	4.1.50

Rebuild a Java project

Common build tools for Java projects, such as Maven, are irrelevant to the architecture. You do not need to modify the build tools. You only need to configure the JDK before you rebuild a Java project. For information about how to select a JDK, see the Select a JDK section of this topic .