# SOFARPC: a Java RPC framework from Ant Financial's SOFAStack > SOFARPC is an Apache-2.0 Java RPC framework with pluggable protocols, registries and load balancing. Here is what the README documents, and where it is the wrong choice. **sofastack/sofa-rpc** — SOFARPC is a high-performance, high-extensibility, production-level Java RPC framework. - Repository: https://github.com/sofastack/sofa-rpc - Website: https://www.sofastack.tech/sofa-rpc/docs/Home - Stars: 3,921 · Forks: 1,203 - Language: Java - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/sofastack-sofa-rpc ## What SOFARPC solves, and for whom SOFARPC targets the point-to-point remote invocation problem inside a Java service estate. The README frames it as a way to "simplify RPC calls between applications" and to provide "no code intrusion" remote service invocation. The intended user is a Java team that already runs multiple services and wants a uniform way to call across them without hand-rolling serialization, connection management or failover logic. The project's own history is part of the pitch: the README states SOFARPC has been used inside Ant Financial for more than ten years and is in its fifth generation. That matters less as a quality claim than as a hint about the design centre. This is a framework built for a large internal service estate before the term service mesh was common, and its abstractions reflect that: filters, routing, load balancing and registries are all listed as extension points rather than fixed behaviour. It is not a general-purpose HTTP client and not a message queue. If your problem is calling a Java method on another host and getting a result back, with policy decisions (which instance, which protocol, which failure handling) configurable per call, that is the shape of problem SOFARPC addresses. ## Protocols, registries and invoke types as pluggable layers The clearest architectural signal is the top-level repository layout. Directories such as codec/, remoting/, registry/, fault/, metrics/, tracer/, config/ and bootstrap/ sit alongside core/ and core-impl/. That split tells you where the seams are: serialization lives in codec/, transport in remoting/, service discovery in registry/, and failure handling in fault/. The README lists the capabilities those modules back: multiple service routing and load balancing policies, multiple service registries, multiple protocols, and multiple invoke types including synchronous, oneway, callback and generalized. Cluster failover, service warm-up and automatic fault tolerance are named as features. The repository's topics list names hessian, http2, protobuf, restful and sofa-bolt, which is consistent with the protocol claim: SOFARPC is not tied to one wire format. The extension model is the point. Filters, routing and load balancing are exposed as interfaces so a team can substitute its own policy without forking the core. The trade-off is that the framework gives you fewer defaults than a single-protocol library would. You are expected to choose a protocol, a registry and a load balancing policy, and those choices interact. ## Requirements, the Maven wrapper, and the first-call example The README states the build-time requirement is JDK 8 or above with Maven 3.2.5 or above, and the runtime requirement is JDK 8 or above. The repository ships a Maven wrapper: mvnw and mvnw.cmd sit at the top level, next to pom.xml. To build the framework from source, clone the repository and run the wrapper from the project root: ```bash ./mvnw ``` Expect the modules under core/, remoting/, codec/ and registry/ to be built and installed into your local Maven repository. The README does not state which flags or profiles to pass, so the plain wrapper invocation is the only starting point the repository itself gives. For application use, the README points at a separate project: sofa-rpc-boot-project, described as "SOFABoot projects for SOFARPC, include starter and samples". That is where the SOFABoot starter and its samples live. The README does not list a Maven coordinate for the starter, so take the groupId and artifactId from that repository rather than guessing. For a first call in plain Java, the in-repo material to read is example/pom.xml and the sources under example/src/. The README links a Getting Started guide and a User Guide on sofastack.tech, and those are the authoritative sources for the provider and consumer API. The README does not reproduce the annotation or API code, so treat the example module and the external guides as the two places to look before writing your first service interface. ## Where SOFARPC is the wrong tool The first limitation is documentation placement. The README is a signpost, not a manual. Getting Started, the User Guide, the Developer Guide, Release Notes and the Road Map all live on sofastack.tech. Anyone evaluating the project from the repository alone will not find the API surface, the configuration keys or the upgrade procedure. That is a real cost during evaluation, because you cannot judge ergonomics without leaving the code host. The second is the JVM boundary. Every requirement in the README is a JDK requirement. There is no documented non-Java client path, so a polyglot estate where the caller is Go, Python or Node needs a different answer for those callers. The third is the cost of choice. SOFARPC supports multiple protocols, multiple registries and multiple invoke types. That flexibility is only an advantage if you have an opinion. A team that wants one sensible default and no configuration will spend more time deciding between sofa-bolt, http2, protobuf and restful than it would spend adopting a framework with a single transport. The README's feature list is a menu, and a menu is a decision burden. Finally, the README does not document rollback, downgrade procedures or compatibility guarantees between minor versions. The release notes on sofastack.tech are the place to check that before pinning a version in production. ## How SOFARPC differs from gRPC and Dubbo in approach gRPC takes the opposite stance on protocol. It is built around HTTP/2 and Protocol Buffers as the single supported combination, with generated stubs from a .proto file as the interface contract. SOFARPC lists protobuf and http2 among its supported protocols but does not require either; the topics list also names hessian, restful and sofa-bolt. If your team wants one wire format and code generation as the source of truth, gRPC's constraint is a feature and SOFARPC's flexibility is friction. Apache Dubbo is the closer comparison. Both are Java RPC frameworks with pluggable protocols, registries and load balancing, and both grew out of large Chinese internet service estates. The practical difference for an adopter is ecosystem alignment rather than architecture: SOFARPC belongs to SOFAStack, and the README directs SOFARPC users to sofa-rpc-boot-project for the SOFABoot starter and samples. If your stack is already SOFABoot, the integration path is documented inside the same project family. If your stack is Spring Cloud or Dubbo-based, adopting SOFARPC means adding a second RPC layer rather than extending the one you have. A useful test: if you cannot name which of SOFARPC's extension points (filter, routing, load balancing, registry) you actually intend to customise, the framework's main differentiator is not doing anything for you. ## Maintenance, releases and the Apache-2.0 licence The repository is not archived, and the last push was on 2026-09-01. The most recent release listed is v5.14.3 on 2026-06-30, preceded by v5.14.2 on 2026-03-11 and v5.14.1 on 2025-11-17. That is a steady cadence across roughly a year, with patch releases rather than major version jumps. Upgrade cost is the part the README leaves open. There is no compatibility matrix in the repository root, and no migration guide is referenced there. The README does link Release Notes on sofastack.tech, which is where a team should look before moving between 5.14.x versions. Because the framework exposes extension interfaces for filters, routing and load balancing, any custom implementation of those interfaces is the code most likely to need attention on upgrade, since it depends on internal contracts rather than the public call API. SOFARPC is licensed under Apache License 2.0, and the README notes that the project "uses some third-party components" whose licences are listed in a separate NOTICE document on sofastack.tech. Apache-2.0 is permissive and includes an explicit patent grant, which is generally the least friction for commercial adoption. The practical obligation is attribution and preservation of notices, and the third-party NOTICE is the file to read before shipping, because bundled components can carry different terms. This is not legal advice; check the NOTICE against your own distribution model. ## Conclusion SOFARPC fits Java teams already inside the SOFAStack ecosystem, or teams that need pluggable protocols, registries and invoke types behind one API and are willing to read the sofastack.tech documentation rather than the README alone. It is a poor fit if you are not on the JVM, if you want a single opinionated transport, or if you need the repository itself to teach you the API: the README points at external docs for Getting Started and the User Guide, and the example/ directory is the only in-repo sample. Before adopting, verify three things in this order: that the sofa-rpc-boot-project starter matches your SOFABoot version, that the registry you actually run has a module under registry/ you can depend on, and that the serialization protocol you plan to use is supported by the codec/ modules present in the tag you pin. Then read the release notes for the version you chose, because the upgrade path is not described in the README. ## FAQ ### What is SOFARPC used for? SOFARPC is a Java RPC framework for point-to-point remote service invocation between applications. The README describes it as providing no-code-intrusion remote calls, with pluggable protocols, registries, routing, load balancing and invoke types. ### What Java version does SOFARPC require? The README states JDK 8 or above for runtime, and JDK 8 or above with Maven 3.2.5 or above for building. ### Is there a Spring Boot starter for SOFARPC? The README points to a separate repository, sofa-rpc-boot-project, described as SOFABoot projects for SOFARPC that include a starter and samples. The README does not list the starter's Maven coordinates. ### What licence is SOFARPC released under? SOFARPC is licensed under the Apache License 2.0. The README notes that the project uses third-party components whose open source licences are listed in a separate NOTICE document on sofastack.tech. ### Which protocols does SOFARPC support? The README states support for multiple protocols, and the repository topics list hessian, http2, protobuf, restful and sofa-bolt. The README does not give a per-protocol compatibility table. ## Sources - [License: Apache-2.0](https://github.com/sofastack/sofa-rpc/blob/master/LICENSE) - [Project website](https://www.sofastack.tech/sofa-rpc/docs/Home) - [README](https://github.com/sofastack/sofa-rpc/blob/master/README.md) - [Releases](https://github.com/sofastack/sofa-rpc/releases) - [sofastack/sofa-rpc on GitHub](https://github.com/sofastack/sofa-rpc) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sofastack-sofa-rpc