Resolving and services <was> Re: ServiceLoader.load* take 2

[Paul Sandoz]

On Jun 18, 2012, at 12:01 PM, Alan Bateman wrote:

> On 18/06/2012 10:00, Paul Sandoz wrote:
>> :
>> Here is my latest thoughts on this:
>> 
>> 1) maintain a separate stack of Choice for service provider modules. When the resolver comes across a service consume module add Choice instances to that stack for all known corresponding service provider modules.
>> 
>> 2) when the main choice stack is null and is about to return true move all the choices on the service stack to the current stack and keep on processing.
>> 
>> To be experimented with soon...
>> 
>> Paul.
> I think this comes down as to whether a service provider module's dependencies (and transitive dependencies) are allowed to change the solution that would otherwise be arrived at if the service provider module were not present. At the moment it can change the solution, meaning that the dependencies are treated equally as it tries to find a solution.
> 

Yes, the key difference is *when* such Choice instances for service provider modules are processed. 

Currently every service consumer module, for the same service interface, adds Choice instances for service provider modules to the stack of the consumer module. That bugs me.

I am trying to work out whether such Choice instances for service provider modules can be stuffed on at the end of what would otherwise be a successful resolution if no "requires service <S>" declarations were present. 

That might result in a more consistent solution. It can potentially allow us to separate out resolving errors.


> Assuming they are to be treated equally then, and with permits out of the equation for service modules, then a possible route is to change the Choice stack so that it is requesting module -> Dependence rather than a ViewDependence. That way it knows whether to check permits or not. The result should be the same as today, assuming that service modules don't have a permits cla

A quick solution to ignore permits is to do:

  new Choice(null, vd, ch);


IIUC part of what you are saying is we no longer need to add a Choice for each view of the module, we just need to add one Choice for the default view if that view or any other view declares "provides service ...".

Does "provides service ..." make sense in the non-default view anymore? I suppose it is harmless but IMHO it would be better to state:

  A non-default view never has a "provides service ..." clauses.

Paul.