Optional service dependencies only was: Direct dependency on service provider modules?

[Paul Sandoz]

Hi,

On Jun 21, 2012, at 11:35 AM, Jaroslav Tulach wrote:

> Hello Paul,
> here is my initial proposal for improving the dependencies mechanism to 
> eliminate the NP-Completeness:
> 
> [1] http://wiki.apidesign.org/wiki/JigsawServices
> 
> Dne Čt 21. června 2012 10:05:27, Jaroslav Tulach napsal(a):
>>> I would very like to do a mind meld with you on this!
>>> 
>>> It's interesting in that, with the current Resolver implementation, when
>>> you push service provider module dependency resolution to the end then
>>> there is no longer any backtracking above those dependencies, since they
>>> are optional.
>> 
>> Are they really optional? What is optional on "requires service xyz"? But...
> 
> As the first part of [1] argues, with "requires service" you always need 
> backtracking.
> 

Nice write up. We are definitely on the same page w.r.t. optionality.

What i was trying to do with my patch is change when those optional dependencies are processed i.e. at the end, thus first the application module dependencies are resolved as if no service provider modules are present.

My hunch is that because service consumers are decoupled from service providers it can be harder to predict or understand the result when the resolver mixes in the resolving of service provider dependencies.


>> Heuréka! I think I know how to overcome the NP-complete problem with
>> services. We need to make sure we make the dependencies optional. E.g.
>> there are no NP- complete problems with "requires service optional xyz".
>> Thus, if we allow only optional services, we simplify everything a lot.
>> 
>> Of course, some "requires service" are not that optional. So the question
>> for me is: how to make the dependency system usable and still pretend all
>> services are in fact optional?
> 
> [1] talks about a "hint". I'd rather leave the exact language construct for 
> providing a hint up to language experts, but I can imagine it makes a logical 
> sense for the language. When I am JAXP module at 1.33 I probably want to 
> recommend Xerces from JDK 1.33 as well. I should have a way to provide such 
> hint to the Jigsaw resolution system.
> 
> However there should be a way to reconfigure these hints at the deployment 
> time.

You raise a very interesting point!

I think this suggests control of versions of transitive dependencies, much like what can be done with maven. Although the JAXP module may hint it strongly wants a version of Xerces another module may strongly hint it wants a different version. Perhaps the conflict could be mediated by changing module processing order, or perhaps by declaring what version should be used.


> I've noticed a discussion about security providers. You were in need of 
> changing their order and that could be also considered a "hint". Just probably 
> a hint provided externally, at the time the application is started (e.g. not 
> compiled).

Yes, although in this case the order is associated with a service interface not the module. Modules can be service provider modules for multiple service interfaces. So hints on the order of service provider classes may need to be something separate to hints on the order modules are resolved.

Paul.