ServiceComb Java Chassis: an interface-first RPC SDK with three release trains

An interface is the unit of definition, not a route table

Apache ServiceComb Java Chassis describes itself as a Software Development Kit for rapid development of microservices in Java, covering service registration, service discovery, dynamic routing and service management. What makes it different from an HTTP client library is where the contract lives. You write an ordinary Spring annotated interface, and both sides of the call derive from it.

@RequestMapping(path = "/provider")
public interface ProviderService {
  @GetMapping("/sayHello")
  String sayHello(@RequestParam("name") String name);
}

That single declaration carries the path, the HTTP method and the parameter binding. The provider implements it, and the consumer holds a proxy of the same type. Because the interface is a real Java type on both ends, consumers can call it through a typed proxy, which is the argument for adopting an RPC SDK over raw HTTP calls.

The provider side is an annotated class with a schema id

On the server, the implementation class is annotated with RestSchema and names both its schema id and the interface it implements:

@RestSchema(schemaId = "ProviderController", schemaInterface = ProviderService.class)
public class ProviderController implements ProviderService {
  @Override
  public String sayHello(String name) {
    return "Hello " + name;
  }
}

schemaInterface is the piece that lets the framework derive the service contract without a separate schema file, and schemaId is the identifier the rest of the system uses to refer to this provider. There is a demo directory that isolates each of these concerns, including demo-schema for schema handling and demo-filter for the handler chain.

Consumers get a proxy from Invoker.createProxy, not an injected client library

The consumer declares the remote service as a bean. The arguments are the service name in the registry and the schema id that matches the provider annotation:

@Configuration
public class ProviderServiceConfiguration {
  @Bean
  public ProviderService providerService() {
    return Invoker.createProxy("provider", "ProviderController", ProviderService.class);
  }
}

There is no base URL, no host, no port. Resolution happens through the registry, which is what lets dynamic routing and load balancing exist at all: the caller names a service and the chassis decides which instance answers. A consuming controller then simply autowires the interface and calls it, so the remote call reads like a local method call.

@RestSchema(schemaId = "ConsumerController", schemaInterface = ConsumerService.class)
public class ConsumerController implements ConsumerService {
  private ProviderService providerService;

  @Autowired
  public void setProviderService(ProviderService providerService) {
    this.providerService = providerService;
  }

The concrete wire behaviour lives in transports/ and clients/ at the top level of the repository, so the transport is a pluggable concern rather than something baked into the API.

Registry choice is a deployment decision, and the demos enumerate the options

The demo directory is the best map of what this SDK expects around it. There are demos for demo-consul, demo-etcd, demo-zookeeper, demo-nacos, and demo-local-registry for running without an external registry, plus demo-multi-registries and demo-multi-service-center for the cases where a deployment talks to more than one registry or more than one service center.

Two more demos show the edge path and cross application routing: demo-edge and demo-crossapp. A zeroconfig-registry demo exists as well, which is the deployment where instances register themselves without a registry server.

That spread is the honest cost picture. The demos show that registry choice is a deployment decision.

Three release trains, and Open API 3 is the hard break

The README publishes a release train table that is worth reading before anything else. Java Chassis 3 at 3.3.0 is compiled and tested on OpenJDK 17 and depends on Spring Boot 3, using Open API 3.0.x. Java Chassis 2 at 2.8.24 is compiled on OpenJDK 8, tested on OpenJDK 8, 11 and 17, depends on Spring 5 and uses Open API 2.0.x. Java Chassis 1 at 1.3.11 is compiled and tested on OpenJDK 8, also Open API 2.0.x, and is marked end of support.

The upgrade note is unambiguous: since Open API 3.0.x is not compatible with 2.0.x, Java Chassis 2 and Java Chassis 1 cannot work together with Java Chassis 3. Every related consumer, provider and edge service needs to move at the same time.

That is the single biggest adoption constraint. Moving to version 3 means the Spring Boot 3 baseline, which in practice means JDK 17 across the estate, and it cannot be done service by service.

Dependency floors are pinned tightly, and the release train gap is the weak point

A second table gives the core dependency versions per minor line. Java Chassis 3.3.x pairs with Spring Boot 3.4.x, Vert.x 4.5.x, Swagger 2.2.x and Jackson 2.18.x. Java Chassis 3.2.x pairs with Spring Boot 3.3.x, Vert.x 4.5.x, Swagger 2.2.x and Jackson 2.18.x.

Two observations follow. Vert.x is listed at 4.5.x on both lines. Jackson is also listed at 2.18.x across both lines.

Recent repository releases are 2.9.5 on 2026-06-23, 2.9.4 on 2026-04-25 and 2.8.31 on 2026-03-16. The last push was on 2026-09-12.

Building from source is optional, and the integration tests need Docker

The README is direct that you do not need to build from source to use the framework, because the binaries are published to the Apache Nexus repository. If you do want to build, the requirement is JDK 17 and Maven:

mvn clean install

The first build is slow because Maven downloads everything. Running the integration tests is a different job: they build a Docker image, so they run under the docker profile.

mvn clean install -Pdocker -Pit

On Docker Machine you add a third profile:

mvn clean install -Pdocker -Pit -Pdocker-machine

The optional switch profiles are therefore not cosmetic. A contributor without a working Docker daemon cannot run the integration suite at all, which separates casual building from actually validating a change.

Where Java Chassis is the wrong tool

The interface first model has a cost when services are not both Java. A contract expressed as a Java interface can generate an Open API description, but the README does not document a first class workflow for a consumer in Go or Python calling a Java Chassis provider with generated stubs. Teams that are genuinely polyglot should assume the interface is a Java side convenience rather than a cross language contract.

The second wrong case is the small service. The repository top level spans core/, transports/, clients/, governance/, handlers/, service-registry/, dynamic-config/, tracing/, metrics/, swagger/, edge/ and huawei-cloud/. That is a large surface to reason about for a service that needs only a small number of endpoints.

Licence is straightforward: Apache License 2.0, with a NOTICE file at the root. For commercial distribution the obligations of that licence are the same ones you would already be handling for any Apache project.

Editorial conclusion

Adopt Java Chassis 3.x if your services are already on Spring Boot 3 and JDK 17 and you want RPC defined by a Java interface rather than by hand written HTTP clients. Do not adopt it for a mixed estate, because the README states that Java Chassis 1 and 2 cannot work with Java Chassis 3 since Open API 3.0.x is not compatible with 2.0.x, so consumers, providers and the edge service must all move together. Verify first that your service registry and configuration sources are covered, and treat Java Chassis 1.3.11 as unavailable since the README marks it end of support.

Frequently asked questions

Official sources

1. apache/servicecomb-java-chassis on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases