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
