[Feature] Support building and running EventMesh on RISC-V 64 (riscv64) platforms

[xwm1992]

Search before asking

• I had searched in the issues and found no similar issues.

Feature Request

Background & Motivation

RISC-V is growing rapidly in edge computing and domestic hardware scenarios. EventMesh (master branch) is written in pure Java and is architecturally close to riscv64-ready, but there is no verified build/run path for RISC-V 64 platforms today.

This issue proposes the complete plan to build and run EventMesh (master) on riscv64 Linux distributions (validated target: Bianbu OS, a Debian-based distro from SpacemiT). The outcome enables EventMesh to run as a lightweight, self-contained message mesh on RISC-V edge devices.

Key Findings (master branch)

• The core is pure Java (source/target = 1.8); bytecode is architecture-independent.
• No RocksDB / JNI-only hard dependency exists in the runtime path of master.
• eventmesh-storage-standalone (Disruptor-based, pure Java, in-memory) ships as the default storage (eventMesh.storage.plugin.type=standalone in eventmesh-runtime/conf/eventmesh.properties) — a zero-external-dependency mode works out of the box.
• AbstractRemotingServer uses Epoll.isAvailable() and falls back to NIO automatically when the Netty native epoll library is unavailable on the arch. Same for grpc-netty-shaded.
• Remaining architecture-sensitive artifacts:
  • kafka-clients (transitive of cloudevents-kafka:2.5.0 in eventmesh-storage-kafka) → snappy-java / zstd-jni native libs
  • Docker base images openjdk:8-jdk / openjdk:11-jdk (no riscv64 variant, deprecated)
  • eventmesh-sdk-c makefile (hardcoded gcc), Go/Rust SDK toolchains

Proposed Changes

1. Runtime JDK constraint (bin/start.sh)

eventmesh-runtime/bin/start.sh hard-checks for Java 8 or 11 (is_java8_or_11) and aborts otherwise. RISC-V distributions mainly provide OpenJDK 17/21 today.

Options:

• Preferred: provide/verify a riscv64 build of JDK 8 or 11 (distro packages, vendor JDK such as Xuantie/Alibaba Dragonwell, or OpenJDK riscv ports).
• Fallback: relax start.sh to accept JDK 17+ — add a unified GC logging branch (-Xlog:gc*:...) and remove obsolete flags (-XX:-UseBiasedLocking was removed in JDK 18). Bytecode level 1.8 is forward-compatible.

2. JVM sizing for resource-constrained boards

bin/start.sh hardcodes -XX:MaxDirectMemorySize=8G and -XX:+AlwaysPreTouch, which are too large for typical RISC-V boards (4–16 GB).

• Make direct-memory size and AlwaysPreTouch configurable via conf/server.env (or reduce defaults).

3. Native library audit

• Add a build-time/CI check that scans dist/lib and dist/plugin/**/*.jar for bundled .so/.dll/.dylib and reports per-arch coverage.
• Verify snappy-java / zstd-jni versions pulled in by kafka-clients contain linux-riscv64 binaries; if not, upgrade or document switching producer compression to gzip/lz4 (lz4-java is pure Java). This item can be skipped entirely when the Kafka storage plugin is not deployed.
• Verify logs show clean NIO fallback (no fatal UnsatisfiedLinkError) for Netty/gRPC on riscv64.

4. Docker support

docker/Dockerfile_jdk8 and Dockerfile_jdk11 are based on openjdk:8-jdk / openjdk:11-jdk, which have no riscv64 variant.

• Add a riscv64-compatible Dockerfile using debian:trixie (official riscv64 image) or a vendor base image, installing OpenJDK via apt and reusing the existing build sequence (generateGrammarSource → build dist -x spotlessJava → installPlugin). Bare-metal deployment remains the recommended path for edge devices.

5. Documentation

• Add a RISC-V porting guide to docs/, covering: toolchain setup (JDK + Gradle 8.7 + Maven mirror), build commands (./gradlew clean dist installPlugin -x spotlessJava), standalone smoke test (ports 10000/10105/10106/10205), JVM tuning, and the native-library audit procedure.

6. Multi-language SDKs (optional follow-ups)

• Go SDK: cross-compile with GOOS=linux GOARCH=riscv64 (no code change expected).
• C SDK (eventmesh-sdks/eventmesh-sdk-c): parameterize CC/AR/RANLIB in the makefile to allow the riscv64-linux-gnu cross toolchain; embedded curl/json-c build from source on-device.
• Rust SDK: add riscv64gc-unknown-linux-gnu target support.

Verification Plan

1. Build on-device (or qemu for compile-gate only): ./gradlew clean dist installPlugin -x spotlessJava -x test.
2. Boot with default standalone storage; verify ports 10000 (TCP), 10105 (HTTP), 10106 (admin), 10205 (gRPC).
3. Publish/subscribe a CloudEvent over HTTP end-to-end (can use eventmesh-examples).
4. Confirm zero native-library loading failures in logs.
5. Optionally add a self-hosted riscv64 GitHub Actions runner for CI.

Risks & Caveats

Risk	Level	Mitigation
No riscv64 JDK 8/11 available in distro repos	Medium	Vendor JDK (Xuantie) or relax start.sh for JDK 17+
Hardcoded MaxDirectMemorySize=8G + AlwaysPreTouch on small boards	Medium	Make configurable / adjust server.env
Old snappy-java/zstd-jni without riscv64 (only when Kafka plugin is used)	Low	Upgrade deps or switch compression codec
Build OOM on low-memory boards	Medium	Lower org.gradle.jvmargs, skip spotless/tests
Network restrictions to services.gradle.org / Maven Central	Medium	Offline Gradle distribution; Aliyun mirror is already configured in root build.gradle

Notes

• This plan is scoped to the master branch; the unified runtime on develop has a different risk profile (RocksDB-based offset store) and is tracked separately.
• No breaking changes are expected: all changes are additive (configuration, scripts, docs, optional Dockerfile).

Happy to take this in stages — starting with (1) runtime verification on a riscv64 device with standalone storage, then the documentation and script improvements.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct *