-
Enhancement
-
Resolution: Unresolved
-
Major
-
None
-
25.0.0.Beta5
-
None
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.