[Feature] Support building and running EventMesh on RISC-V 64 (riscv64) platforms
- Dominant language
- Java
- Stars
- 1.8k
- Forks
- 658
- Avg merge
- 11h 29m
- Merged PRs (30d)
- 52
Description
### Search before asking
- [x] I had searched in the [issues](https://github.com/apache/eventmesh/issues?q=is%3Aissue) 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](https://www.apache.org/foundation/policies/conduct) *
Contributor guide
Research direction
Start with eventmesh-runtime/bin/start.sh, docker/Dockerfile_jdk8, and docker/Dockerfile_jdk11 to map the runtime and image constraints. Run the stated Gradle build and standalone smoke test on riscv64 or qemu, then review the native-library audit and docs/ requirements. Done means a documented, verified build and run path with the listed ports working and no native-library loading failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, java
- Domain
- build-system, devops, documentation, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100