Optional service dependencies only

[Jaroslav Tulach]

Dne Čt 21. června 2012 14:14:29, Paul Sandoz napsal(a):
> On Jun 21, 2012, at 11:35 AM, Jaroslav Tulach wrote:
> > [1] http://wiki.apidesign.org/wiki/JigsawServices
> Nice write up. We are definitely on the same page w.r.t. optionality.

Right. Although, I would not call it optional. Each individual service 
implementation is optional, but the resolution fails if none can be enabled.

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

This is what should happen, with following clarification: I am still operating 
in context of "complete repository" - e.g. I assume that the whole set of 
transitive dependencies of a module has been computed and recorded at compile 
time[1]. Only under such assumption range dependencies are acceptable, as far 
as I understand the problem.

[1] http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed#No_Longer_NP-
Complete

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

Right. "Classpath" dependencies first, services later is going to be more 
understandable to humans.

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

#2 - the application vendor (providing the application module) knows all the 
modules in its application and all the services and can decide certain 
services should have different default (this is what Maven tried to do with 
its "shortest" path dependency). Also when compiling the whole application, it 
should be easy to decide whether different services are compatible with the 
rest of modules or not as one knows the transitive closure of the whole 
application.

#3 - a deployer should have the option to override the application defaults 
without coding in Java, imho. E.g. something like:

$ java \
  -module com.myapp.xsltproc \
  -service javax.xml.parser.DocumentBuilderFactory \
  -default org.apache.crimson.CrimsonBuilderFactory

...of course one needs to install com.myapp.xsltproc module into the library 
(is it the right term, I am still learning the terminology) as well as 
org.apache.crimson module, so the resolver can enable both.

#3a - the same using some configuration file which format is beyond the scope 
of my current thinking


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

Good point. The order needs to be associated with service interface types. 
Btw. NetBeans have an order of modules defined by topological sort on top of 
graph with "requires" edges (not "requires service"). This graph is used for 
startup and shutdown order. But services are orthogonal to this concept, they 
have their own ordering (per interface type, in general).

-jt

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

PS: What exactly order of modules is good for in Jigsaw?

PPS: In NetBeans it is used for order of activators and also for order of URLs 
returned from systemWideClassLoader.getResources(...). It is guaranteed 
resources are returned in topological order with respect to order of modules.