Strawman: Services and service-providers support

[Stanley M. Ho]

Hi Glyn,

Glyn Normington wrote:
> Maybe it's just a matter of presentation in the strawman, but it
> confused me somewhat and the net effect was that I wasn't sure what
> pieces JSR 277 will be providing and what pieces are upgrades of
> existing facilities (since I'm not familiar with the existing
> service/service-provider model) to take advantage of JSR 277.
>
> 1. The opening paragraph of the Background section defines a service as
> "a well-known set of interfaces and (usually abstract) classes" - no
> mention of instances,
>
> 2. The third paragraph of the same section say "a service is represented
> by a single type ...". Again no mention of instances.

These text are borrowed from the ServiceLoader API. I will look into
clarifying it.

> 3. The requirements section talks about the module system making
> services available to the Java platform. This is using 'service' in the
> above sense, but I'm not sure what it means to make an interface
> "available to the Java platform" unless it means "available for modules
> to import".

It basically means two things:

1. The service module is available for other modules to import.
2. If the service module is deployed in one of the system repositories,
the service in the service module is available to both the module-based
and non-module-based applications when they call ServiceLoader.load().

> 4. Section 6 talks about an application module importing a service
> module if and only if there is at least one suitable service provider. I
> guess the rationale is to make the application module fail to resolve if
> it hasn't a (current) hope of obtaining the service it needs. But from
> my perspective this is odd. The service provider could be available
> without it being possible to obtain a service instance, which is the
> thing the application really needs. So rather than being an import-time
> check, the availability of critical services should be checked when the
> application module starts (for static applications that don't need to
> react dynamically to services coming online, that is).

Right, in typical cases, the availability should be checked at runtime
instead of during initialization. What I wanted to show in the strawman
was how it might be supported if we wanted to do the checking during
initialization using the declarative approach, but the strawman also
suggested that this was probably not a good idea and the custom import
policy should be the right way to go.

Most of the Section 4,5,6, and 8 are what I have in mind that belong to
277. I think it will become more clear after I extract the pieces into
the next revision of the spec so the EG can review and discuss.

- Stanley