Offer default was: Optional service dependencies only

[Paul Sandoz]

Hi,

On Jun 22, 2012, at 6:59 PM, Jaroslav Tulach wrote:
> 
> Paul wrote:
>> Every module declares what it needs with "requires ...". Perhaps it is a lack of imagination on 
>> my part but i don't currently see how we can strengthen that need in a decentralized 
>> environment. It is not when it all comes together that such needs can be compared?
> 
> The way to eliminate NP-Completeness is to require a hint. So a JAXP module can either say:
> 
> requires service optional javax.xml.parsers.DocumentBuilderFactory;
> 
> and that is fine. Such definition does not need hints, as it is trivially satisfied with nothing, so the resolution algorithm is simple. On the other hand the JAXP module can require real implementation:
> 
> requires service javax.xml.parsers.DocumentBuilderFactory default from com.oracle.apache.xerces at 1.8
> 
> By giving hint - e.g. by directly specifying that the default implementation of XML parser is known (at the time of compilation) to be provided by com.oracle.apache.xerces at 1.8 module, we can avoid NP-Completeness from the system. I can formalize the concept, if there is an interest.
> 

Some questions:

1) when would the dependency "com.oracle.apache.xerces at 1.8" get resolved?
     
2) what if other service provider modules for javax.xml.parsers.DocumentBuilderFactory are present in the library?


My attempt to answer:

1) it would be resolved as non-optional service provider module dependency iff no other service provider modules are present

2) it would be resolved after the other service provider module dependencies, thus would appear last when iterating over the service instances.



> Can the Jigsaw gang consider this little change in "requires service" grammar?
> -jt
> 
>> #3a - the same using some configuration file which format is beyond the scope 
>> of my current thinking
>> 
> 
> Paul wrote:
>> Or part of a module-info that declares entry points.
> 
> PS: Well, the whole point of #3 and #3a is to do this configuration change without any compilation. So it cannot be in in module-info.java that would be the case #2.
> 

Doh.

Paul.