services, take 1

[Neil Bartlett]

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.

Regards,
Neil




On Monday, 19 December 2011 at 12:41, David Bosschaert wrote:

> You can't wait for the loader to be GC'ed because if there are clients
> that still hold on to the services provided by that module it will
> never get GCed.
> 
> It might be easiest to explain with the way OSGi actually does this.
> In OSGi, modules can be stopped (there is a stop() call on the
> Bundle). There is a callback associated with this, which allows the
> module to clean up. One of the things this typically does is
> un-register any services provided by this module. In OSGi this service
> unregistration event causes further callbacks on any service consumers
> which means they will dereference the unregistered service. The whole
> thing makes it possibly to actually GC the stopped module's
> classloader in the first place.
> 
> Maybe we can facilitate something similar with ServiceLoader, for
> example by allowing it to register a listener which gets called back
> when certain services need to be dereferenced by clients. But I'm sure
> other approaches are also possible.
> 
> There is still the risk of badly coded clients that don't give up the
> service object. Maybe we could do something for those too, but in
> general I think that can considered to be a programming error/memory
> leak.
> 
> Cheers,
> 
> David
> 
> On 19 December 2011 11:54, Alan Bateman <Alan.Bateman at oracle.com (mailto:Alan.Bateman at oracle.com)> wrote:
> > On 19/12/2011 10:30, David Bosschaert wrote:
> > > 
> > > I have been looking at using ServiceLoader inside OSGi and one of the
> > > biggest problems is (IMHO) that it's completely static. This means
> > > that once a service is handed out to a consumer this client has that
> > > reference forever (basically as long as that client exists). The
> > > consumer may not actually hold on to the reference, but ServiceLoader
> > > has no control over that.
> > > 
> > > I think it would be really good to add a mechanism to ServiceLoader
> > > that could inform a consumer that a service is now removed. This would
> > > mean that in more dynamic environments, such as OSGi, where modules
> > > can be removed during the lifetime of the VM, it would be possible to
> > > create clients such that they won't hold on to handed out services
> > > forever...
> > 
> > 
> > Can you expand a bit on what you mean by "remove"? Do you mean that the
> > module loader for a module providing a service has been GC'ed, or do you
> > mean a module providing a service is removed from a module library? Or maybe
> > you looking to "disable" a module that a provides a service so that
> > ServiceLoader will not return any further references to instances of that
> > type?
> > 
> > -Alan.