Offer default

[Jaroslav Tulach]

Hello Paul,
 
> 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:

There are important questions! I can either reply from the point of view of 
someone trying to eliminate NP-Completeness, or from a point of view of user 
of such dependency system.

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

The NP-Aware guy would suggest to follow the hint first. E.g. try the service 
that has been hinted - either by "default from" definition or by any other 
hint made by the assembler or deployer of the whole application. Only later 
fallback to trying all the services available and enabling those that can be 
enabled.

This prevents the system to be trapped in insolvable situation due to trying 
some weird service provider first and then preventing all others to be found 
incompatible.

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

Possible. But this does not guarantee success. As I mentioned above, you may 
get to situation when for soem requested services a provider can't be enabled. 
If that happens you can either do the NP-Complete algorithm or throw away all 
your computation and try again following the hinted service at first.


There is one thing that is not very nice on my proposal. It seems to me (a 
rigorous proof would clarify it) that when composing the transitive 
dependencies of a module, one needs to take into account the "default with". 
E.g. in the above case:

requires service javax.xml.parsers.DocumentBuilderFactory default from
com.oracle.apache.xerces at 1.8

When compiling a module against JAXP one would have to have the Xerces at 1.8 
module around and the transitive dependencies of the new module would include 
not only all dependencies of JAXP, but also of Xerces at 1.8. Sounds strange, but 
it may not be as bad:

#1 - when compiling against standard JavaSE at 1.8 the JAXP API as well as 
Xerces at 1.8 are already present. It is not restrictive at all.

#2 - when compling against smaller Java (without Xerces at 1.8) one would need to 
have different hint.
#2a - the module itself could use 
requires service javax.xml.parsers.DocumentBuilderFactory default from
org.w3c.lightweightparser at 3.7
#2b - among the dependencies of the new module, there could be some which 
specifies the different default. E.g. JavaME at 1.8 could 
requires service javax.xml.parsers.DocumentBuilderFactory default from
org.w3c.lightweightparser at 3.7
and then whoever compiles against JavaME would get the right one.

So the "default from" restriction seems to be sort of acceptable in practise, 
imho.
-jt