services, take 1

[Alan Bateman]

On 20/12/2011 11:00, Neil Bartlett wrote:
> I think that before dynamics, the first problem that needs to be solved is to provide hooks that will allow "findability" of services in non-flat classloading models. The lack of visibility into module classloaders was the principal challenge with ServiceLoader usage in OSGi, even more so than the lack of dynamics. Incidentally I do feel that it was a very poor decision to put ServiceLoader into the `java.*` namespace, meaning it cannot be overridden or extended.
>
> If there is scope for API modifications in JDK8 then perhaps a ServiceLoaderExtension interface could be added, which would itself be a service published through META-INF/services. Then an OSGi framework or other module system could provide extensions enabling interop between the JRE and OSGi service models.
>
> With respect to dynamics, there is an argument for adding API to support registration and unregistration, along with corresponding events and listeners, even if they are never used in Jigsaw. Frankly I don't see dynamics being relevant in Jigsaw or the JDK8 module system so long as modules are static and services are statically declared through META-INF/services/* files. When a dynamic system like OSGi must supply a service to a static system like Jigsaw, we can use the standard fallback of a proxy that internally rebinds to the real service.
>
In a container environment with managed services then dynamic 
registration, life cycle events, etc. are obviously important but maybe 
a bit beyond (or further up the stack) from what we are doing here.

On "findability" then in this first patch the linker has already linked 
modules that require a service to those that provide implementations of 
the service and this is what ServiceLoader uses at runtime. Clearly 
there a bit of an API mismatch and that's what we need to work through. 
There aren't any additions to ModuleClassLoader or other APIs at this time.

-Alan.