[Task] Add Linux/riscv64 support for HugeGraph

[imbajin]

Summary

Add and document Linux/riscv64 support for HugeGraph.

HugeGraph is mostly Java, and OpenJDK already has a Linux/RISC-V port in mainline. The remaining work is to verify and adapt the native-binary parts of our build/runtime chain: JDK distribution, RocksDB JNI, protobuf/gRPC code generation, Docker images, and optional native runtime libraries.

flowchart TD
    A[HugeGraph on linux/riscv64] --> B[JDK 11+ runtime]
    A --> C[Maven build]
    A --> D[Storage backend]
    A --> E[Docker image]
    A --> F[CI / test path]

    B --> B1[OpenJDK Linux/RISC-V RV64G/RV64GC]
    C --> C1[protoc + protoc-gen-grpc-java binaries]
    D --> D1[RocksDBJNI native library]
    E --> E1[riscv64-capable base images]
    F --> F1[QEMU smoke tests]
    F --> F2[optional native riscv64 runner]

Loading

Why this is useful

RISC-V hardware and Linux distributions are becoming more practical for server-side testing. Supporting riscv64 would let HugeGraph users run and test HugeGraph on RISC-V boards, VMs, and future RISC-V servers.

This is a good newcomer-friendly task because it can be split into small, verifiable steps. Contributors do not need physical RISC-V hardware for the first round of work.

Current context

From a quick repository check:

• HugeGraph currently compiles with Java 11 target/source in the root pom.xml.
• Current CI mainly runs on GitHub-hosted x86 Linux runners.
• Dockerfiles use Temurin 11 based images today.
• PD/Store gRPC modules download platform-specific protoc and protoc-gen-grpc-java executables via ${os.detected.classifier}.
• RocksDB is a key default/native dependency for the server and distributed modules.
• start-hugegraph-store.sh currently handles aarch64/arm64 and x86_64 for jemalloc, but not riscv64.

Upstream / platform facts to verify against

• OpenJDK RISC-V Port Project targets Linux/RISC-V and the OpenJDK wiki says the port supports RV64G, template interpreter, C1, C2, and current mainline GCs. It also says RISC-V is in JDK mainline and can be tried with QEMU user/system mode or hardware.
  • https://openjdk.org/projects/riscv-port/
  • https://wiki.openjdk.org/display/RISCVPort/Main
• Eclipse Temurin currently publishes Linux/riscv64 JDK builds for newer LTS lines such as JDK 17 and JDK 21 via the Adoptium API, while JDK 11 riscv64 availability should be checked before relying on it.
  • https://api.adoptium.net/v3/assets/latest/17/hotspot?architecture=riscv64&image_type=jdk&os=linux&vendor=eclipse
  • https://api.adoptium.net/v3/assets/latest/21/hotspot?architecture=riscv64&image_type=jdk&os=linux&vendor=eclipse
  • https://api.adoptium.net/v3/assets/latest/11/hotspot?architecture=riscv64&image_type=jdk&os=linux&vendor=eclipse
• Debian 13 officially supports riscv64; Debian also documents RV64GC + lp64d as the baseline for its port.
  • https://www.debian.org/releases/stable/release-notes/whats-new.html
  • https://wiki.debian.org/RISC-V
• Ubuntu provides RISC-V images and QEMU instructions. Note that Ubuntu 25.10+ raises the required ISA profile to RVA23S64; Ubuntu 24.04 LTS is usually a safer first target for broad VM testing.
  • https://ubuntu.com/download/risc-v/canonical-built
  • https://ubuntu.com/hardware/docs/boards/how-to/ubuntu_supported/qemu-riscv/
• Docker Buildx supports multi-platform builds using QEMU emulation, but emulation can be much slower than native builds.
  • https://docs.docker.com/build/building/multi-platform/

Suggested task breakdown

1. Define the support target

Suggested first target:

• OS: Linux riscv64
• CPU/ABI: 64-bit little-endian RISC-V, RV64GC/RV64G-compatible, lp64d
• JDK: Java 17 or 21 for the first practical smoke tests; keep Java 11 bytecode compatibility unless the project decides otherwise
• Backend smoke target: memory first, then rocksdb

2. Make the build work on riscv64

Check and fix:

• os-maven-plugin classifier output on Linux/riscv64.
• com.google.protobuf:protoc:*:exe:${os.detected.classifier} availability.
• io.grpc:protoc-gen-grpc-java:*:exe:${os.detected.classifier} availability.
• Fallback options when upstream does not publish riscv64 executables:
  • use system-installed protoc, or
  • build protoc-gen-grpc-java from source, or
  • document a temporary riscv64 build profile.

3. Make the runtime work

Check and fix:

• memory backend startup on riscv64.
• rocksdb backend startup on riscv64.
• Whether the current rocksdbjni artifact contains a riscv64 native library. If not, document/build a riscv64 RocksDB JNI artifact or find an upstream-supported version.
• Optional jemalloc handling for Store: either add riscv64 support or make the current “unsupported architecture” path clearly non-fatal.

4. Add a no-hardware developer test path

Document a path like this:

x86_64 / arm64 laptop
        |
        | QEMU system VM or Docker Buildx + QEMU
        v
Linux riscv64 guest/container
        |
        | install JDK + Maven + native build deps
        v
mvn compile / selected tests / HugeGraph smoke startup

Recommended first checks:

uname -m
java -version
mvn -version
mvn clean compile -Dmaven.javadoc.skip=true -ntp
mvn test -pl hugegraph-server/hugegraph-test -am -P unit-test -ntp
mvn test -pl hugegraph-server/hugegraph-test -am -P core-test,memory -ntp

Then test RocksDB when the native dependency story is clear:

mvn test -pl hugegraph-server/hugegraph-test -am -P core-test,rocksdb -ntp

5. Optional CI follow-up

Once the manual smoke path works:

• add a lightweight riscv64 workflow using QEMU for compile/smoke tests, or
• document how maintainers can attach a riscv64 self-hosted runner for fuller tests.

Acceptance criteria

This task can be considered done when:

• The project documents the intended Linux/riscv64 support target: OS, CPU/ABI, JDK version, and tested backends.
• mvn clean compile -Dmaven.javadoc.skip=true -ntp works in a documented riscv64 environment, or any remaining upstream blocker is clearly documented.
• At least memory backend tests or smoke startup are verified on riscv64.
• RocksDB support is either verified on riscv64 or documented as blocked by a specific upstream/native-library gap.
• Developers without RISC-V hardware can reproduce the smoke test with QEMU or Docker Buildx/QEMU.
• The docs explain the known limitations and the expected follow-up work for CI/native runners.

Notes for first-time contributors

You can start without a RISC-V board. The best first PR would be a documentation PR that records a working QEMU setup and the first failing command, if any. After that, smaller code/build fixes can be done one by one.

[imbajin]

Closing this premature duplicate: the research and scope review were not complete. Any follow-up should be a single consolidated issue focused only on HugeGraph Server with the RocksDB backend on linux/riscv64.