Background Information

ShardingSphere JDBC has been validated for availability under GraalVM Native Image.

Build GraalVM Native containing Maven dependencies of org.apache.shardingsphere:shardingsphere-jdbc:${shardingsphere.version} Image, you need to resort to GraalVM Native Build Tools. GraalVM Native Build Tools provides Maven Plugin and Gradle Plugin to simplify long list of shell commands for GraalVM CE’s native-image command line tool.

ShardingSphere JDBC requires GraalVM Native Image to be built with GraalVM CE as follows or higher. Users can quickly switch JDK through SDKMAN!. Same reason applicable to downstream distributions of GraalVM CE such as Oracle GraalVM, Liberica Native Image Kit and Mandrel.

  • GraalVM CE 23.1.2 For JDK 21.0.2, corresponding to 21.0.2-graalce of SDKMAN!
  • GraalVM CE 24.0.0 For JDK 22, corresponding to 22-graalce of SDKMAN!

Maven Ecology

Users need to actively use the GraalVM Reachability Metadata central repository. The following configuration is for reference to configure additional Maven Profiles for the project, and the documentation of GraalVM Native Build Tools shall prevail.

  1. <project>
  2.      <dependencies>
  3.          <dependency>
  4.              <groupId>org.apache.shardingsphere</groupId>
  5.              <artifactId>shardingsphere-jdbc</artifactId>
  6.              <version>${shardingsphere.version}</version>
  7.          </dependency>
  8.      </dependencies>
  10.      <build>
  11.          <plugins>
  12.              <plugin>
  13.                  <groupId>org.graalvm.buildtools</groupId>
  14.                  <artifactId>native-maven-plugin</artifactId>
  15.                  <version>0.10.1</version>
  16.                  <extensions>true</extensions>
  17.                  <configuration>
  18.                     <buildArgs>
  19.                        <buildArg>-H:+AddAllCharsets</buildArg>
  20.                     </buildArgs>
  21.                  </configuration>
  22.                  <executions>
  23.                      <execution>
  24.                          <id>build-native</id>
  25.                          <goals>
  26.                              <goal>compile-no-fork</goal>
  27.                          </goals>
  28.                          <phase>package</phase>
  29.                      </execution>
  30.                      <execution>
  31.                          <id>test-native</id>
  32.                          <goals>
  33.                              <goal>test</goal>
  34.                          </goals>
  35.                          <phase>test</phase>
  36.                      </execution>
  37.                  </executions>
  38.              </plugin>
  39.          </plugins>
  40.      </build>
  41. </project>

Gradle Ecosystem

Users need to actively use the GraalVM Reachability Metadata central repository. The following configuration is for reference to configure additional Gradle Tasks for the project, and the documentation of GraalVM Native Build Tools shall prevail. Due to the limitations of Gradle 8.6, users need to introduce the JSON file of Metadata Repository through Maven dependency. Reference https://github.com/graalvm/native-build-tools/issues/572 .

  1. plugins {
  2.    id 'org.graalvm.buildtools.native' version '0.10.1'
  3. }
  5. dependencies {
  6.    implementation 'org.apache.shardingsphere:shardingsphere-jdbc:${shardingsphere.version}'
  7.    implementation(group: 'org.graalvm.buildtools', name: 'graalvm-reachability-metadata', version: '0.10.1', classifier: 'repository', ext: 'zip')
  8. }
  10. graalvmNative {
  11.    binaries {
  12.       main {
  13.          buildArgs.add('-H:+AddAllCharsets')
  14.       }
  15.       test {
  16.          buildArgs.add('-H:+AddAllCharsets')
  17.       }
  18.    }
  19.    metadataRepository {
  20.       enabled.set(false)
  21.    }
  22. }

For build tools such as sbt that are not supported by GraalVM Native Build Tools

Such requirements require opening additional issues at https://github.com/graalvm/native-build-tools and providing the Plugin implementation of the corresponding build tool.

Usage restrictions

  1. The following algorithm classes are not available under GraalVM Native Image due to the involvement of https://github.com/oracle/graal/issues/5522.
    • org.apache.shardingsphere.sharding.algorithm.sharding.inline.InlineShardingAlgorithm
    • org.apache.shardingsphere.sharding.algorithm.sharding.inline.ComplexInlineShardingAlgorithm
    • org.apache.shardingsphere.sharding.algorithm.sharding.hint.HintInlineShardingAlgorithm

For general cases, users can simulate the behavior of GroovyShell by themselves through the CLASS_BASE algorithm. For example, take the following configuration.

  1. rules:
  2. - !SHARDING
  3.    defaultDatabaseStrategy:
  4.        standard:
  5.          shardingColumn: user_id
  6.          shardingAlgorithmName: inline
  7.    shardingAlgorithms:
  8.      inline:
  9.        type: INLINE
  10.        props:
  11.          algorithm-expression: ds_${user_id % 2}
  12.          allow-range-query-with-inline-sharding: false

You can first define the implementation class of CLASS_BASE.

  1. package org.example.test;
  3. import org.apache.shardingsphere.sharding.api.sharding.standard.PreciseShardingValue;
  4. import org.apache.shardingsphere.sharding.api.sharding.standard.RangeShardingValue;
  5. import org.apache.shardingsphere.sharding.api.sharding.standard.StandardShardingAlgorithm;
  7. import java.util.Collection;
  9. public final class TestShardingAlgorithmFixture implements StandardShardingAlgorithm<Integer> {
  11.     @Override
  12.     public String doSharding(final Collection<String> availableTargetNames, final PreciseShardingValue<Integer> shardingValue) {
  13.         String resultDatabaseName = "ds_" + shardingValue.getValue() % 2;
  14.         for (String each : availableTargetNames) {
  15.             if (each.equals(resultDatabaseName)) {
  16.                 return each;
  17.             }
  18.         }
  19.         return null;
  20.     }
  22.     @Override
  23.     public Collection<String> doSharding(final Collection<String> availableTargetNames, final RangeShardingValue<Integer> shardingValue) {
  24.         throw new RuntimeException("This algorithm class does not support range queries.");
  25.     }
  26. }

Modify the relevant YAML configuration as follows.

  1. rules:
  2. - !SHARDING
  3.    defaultDatabaseStrategy:
  4.        standard:
  5.          shardingColumn: user_id
  6.          shardingAlgorithmName: inline
  7.    shardingAlgorithms:
  8.      inline:
  9.          type: CLASS_BASED
  10.          props:
  11.            strategy: STANDARD
  12.            algorithmClassName: org.example.test.TestShardingAlgorithmFixture

Add the following content to src/main/resources/META-INF/native-image/exmaple-test-metadata/reflect-config.json to used normally under GraalVM Native Image.

  1. [
  2. {
  3.    "name":"org.example.test.TestShardingAlgorithmFixture",
  4.    "methods":[{"name":"<init>","parameterTypes":[] }]
  5. }
  6. ]
  1. For the ReadWrite Splitting feature, you need to use other implementations of Row Value Expressions SPI to configure logic database name, writeDataSourceName and readDataSourceNames when bypassing calls to GroovyShell. One possible configuration is to use the Row Value Expressions SPI implementation of LITERAL.
  1. rules:
  2. - !READWRITE_SPLITTING
  3.    dataSources:
  4.      <LITERAL>readwrite_ds:
  5.        writeDataSourceName: <LITERAL>ds_0
  6.        readDataSourceNames:
  7.          - <LITERAL>ds_1
  8.          - <LITERAL>ds_2

The same applies to actualDataNodes for the Sharding feature.

  1. - !SHARDING
  2.    tables:
  3.       t_order:
  4.          actualDataNodes: <LITERAL>ds_0.t_order_0, ds_0.t_order_1, ds_1.t_order_0, ds_1.t_order_1
  5.          keyGenerateStrategy:
  6.             column: order_id
  7.             keyGeneratorName: snowflake

  1. Users still need to configure GraalVM Reachability Metadata for independent files in the src/main/resources/META-INF/native-image folder or src/test/resources/META-INF/native-image folder. Users can quickly collect GraalVM Reachability Metadata through the GraalVM Tracing Agent of GraalVM Native Build Tools.

  2. Maven modules such as com.microsoft.sqlserver:mssql-jdbc, represented by the JDBC Driver of MS SQL Server, will dynamically load different character sets based on the encoding used in the database, which is unpredictable behavior. When encountering the following Error, users need to add the buildArg of -H:+AddAllCharsets to the configuration of GraalVM Native Build Tools.

  1. Caused by: java.io.UnsupportedEncodingException: Codepage Cp1252 is not supported by the Java environment.
  2.  com.microsoft.sqlserver.jdbc.Encoding.checkSupported(SQLCollation.java:572)
  3.  com.microsoft.sqlserver.jdbc.SQLCollation$SortOrder.getEncoding(SQLCollation.java:473)
  4.  com.microsoft.sqlserver.jdbc.SQLCollation.encodingFromSortId(SQLCollation.java:501)
  5.  [...]
  1. When using Seata’s BASE integration, users need to use a specific io.seata:seata-all:1.8.0 version to avoid using the ByteBuddy Java API, and exclude the outdated Maven dependency of org.antlr:antlr4-runtime:4.8 in io.seata:seata-all:1.8.0. Possible configuration examples are as follows,
  1. <project>
  2.     <dependencies>
  3.       <dependency>
  4.          <groupId>org.apache.shardingsphere</groupId>
  5.          <artifactId>shardingsphere-jdbc</artifactId>
  6.          <version>${shardingsphere.version}</version>
  7.       </dependency>
  8.       <dependency>
  9.          <groupId>org.apache.shardingsphere</groupId>
  10.          <artifactId>shardingsphere-transaction-base-seata-at</artifactId>
  11.          <version>${shardingsphere.version}</version>
  12.       </dependency>
  13.       <dependency>
  14.          <groupId>io.seata</groupId>
  15.          <artifactId>seata-all</artifactId>
  16.          <version>1.8.0</version>
  17.          <exclusions>
  18.             <exclusion>
  19.                <groupId>org.antlr</groupId>
  20.                <artifactId>antlr4-runtime</artifactId>
  21.             </exclusion>
  22.          </exclusions>
  23.       </dependency>
  24.     </dependencies>
  25. </project>

Contribute GraalVM Reachability Metadata

The verification of ShardingSphere’s availability under GraalVM Native Image is completed through the Maven Plugin subproject of GraalVM Native Build Tools. By running the unit test under the JVM, label the unit test with junit-platform-unique-ids*, and then build it as GraalVM Native Image for nativeTest to test Unit Test Coverage under GraalVM Native Image. Please do not use io.kotest:kotest-runner-junit5-jvm:5.5.4 and some third-party test libraries, they are in test listener mode failed to discover tests.

ShardingSphere defines the Maven Module of shardingsphere-test-native to provide a small subset of unit tests for native Test. This subset of unit tests avoids the use of third-party libraries such as Mockito that are not available under native Test.

ShardingSphere defines the Maven Profile of nativeTestInShardingSphere for executing nativeTest for the shardingsphere-test-native module.

Assuming that the contributor is under a new Ubuntu 22.04.3 LTS instance, Contributors can manage the JDK and tool chain through SDKMAN! through the following bash command, and execute nativeTest for the shardingsphere-test-native submodule.

You must install Docker Engine to execute testcontainers-java related unit tests.

  1. sudo apt install unzip zip curl sed -y
  2. curl -s "https://get.sdkman.io" | bash
  3. source "$HOME/.sdkman/bin/sdkman-init.sh"
  4. sdk install java 21.0.2-graalce
  5. sdk use java 21.0.2-graalce
  6. sudo apt-get install build-essential libz-dev zlib1g-dev -y
  8. git clone git@github.com:apache/shardingsphere.git
  9. cd ./shardingsphere/
  10. ./mvnw -PnativeTestInShardingSphere -T1C -e clean test

When contributors discover that GraalVM Reachability Metadata is missing for a third-party library not related to ShardingSphere, they should open a new issue and submit PR containing the missing third-party library GraalVM Reachability Metadata that depends on https://github.com/oracle/graalvm-reachability-metadata . ShardingSphere actively hosts the GraalVM Reachability Metadata of some third-party libraries in the shardingsphere-infra-reachability-metadata submodule.

If nativeTest execution fails, preliminary GraalVM Reachability Metadata should be generated for unit tests and manually adjusted to fix nativeTest. If necessary, use the org.junit.jupiter.api.condition.DisabledInNativeImage annotation or the org.graalvm.nativeimage.imagecode System Property blocks some unit tests from running under GraalVM Native Image.

ShardingSphere defines the Maven Profile of generateMetadata, which is used to carry GraalVM Reachability Metadata. Bring GraalVM Tracing Agent under GraalVM JIT Compiler to perform unit testing, and generate or merge existing GraalVM Reachability Metadata files in a specific directory. This process can be easily handled with the following bash command. Contributors may still need to manually adjust specific JSON entries and GraalVM Tracing Agent Filter chain of Maven Profile.

The following command is only an example of using shardingsphere-test-native to generate GraalVM Reachability Metadata in Conditional form. Generated GraalVM Reachability Metadata is located under the shardingsphere-infra-reachability-metadata submodule.

For GraalVM Reachability Metadata used independently by test classes and test files, contributors should place ${user.dir}/infra/nativetest/src/test/resources/META-INF/native-image/shardingsphere-test-native-test-metadata/ folder. ${} contains the regular system variables of POM 4.0 corresponding to the relevant submodules, which can be replaced by yourself.

  1. git clone git@github.com:apache/shardingsphere.git
  2. cd ./shardingsphere/
  3. ./mvnw -PgenerateMetadata -DskipNativeTests -e -T1C clean test native:metadata-copy

Please manually delete JSON files without any specific entries.