RuntimeCapability and its Builder have always been a bit awkward to use. This is mostly because the same implementation attempts to describe three different types of capabilities:

• Those defined via RuntimeCapability<Void> that provide no value and merely represent the existence of some resource
• Those defined via RuntimeCapability<T> that provide a fixed value, defined at registration time, and obtained via OperationContext.getCapabilityRuntimeAPI(Class<T>)
• Those defined via RuntimeCapability<Void> that provide a value obtained via service dependency, e.g. RequirementServiceBuilder.requires(<service-descriptor>). It has always struck me as particularly strange that the service type is not reflected by the generic type parameter.

Ideally, each type of capability would be encapsulated by a distinct interface, e.g.

• ResourceCapability, untyped
• RuntimeAPICapability<T>, where T defines the runtime API type
• RuntimeServiceCapability<T>, where T defines the service type

For compatibility, the implementation classes for each type would extend the existing RuntimeCapability<?>. We'd also want to create a ServiceDescriptor analogs for RuntimeAPIs for use with the OperationContext/CapabilityServiceSupport methods used to obtain these values.