services, take 1

[David Bosschaert]

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> 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.