Offer default was: Optional service dependencies only

[Jaroslav Tulach]

Hello.
I've just send a message asking whether having "Optional service dependencies only" is acceptable. Now I will continue this doublethink and assume the answer to that question is "No way!". 

For example the JAXP API. While it can always throw FactoryConfigurationException when the required service is not present, it is not very polite for the API users. The only reason to have dependency on the JAXP API is to parse something, so the implementation is in fact not "optional" service at all. Can we eliminate the NP-Complete nature of the resolution algorithm and still support "requires service"?

Executive summary is "Yes, we can". Explanation of what would have to be done follows...

>>> 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.
> 
> The general principle should be: the one that knows more should make the 
> decision. That is why:
> 
> #1 - a JAXP API knows it needs an implementation and knows Xerces module 
> provides one that is good enough
> 

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.

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.