Mandatory service requirement

[Alan Bateman]

On 17/02/2012 16:15, Jesse Glick wrote:
> :
>
>> it would be preferable to catch such issues at install time rather 
>> than failing at runtime.
>
> It would be preferable, yes - the question is whether this minor bit 
> of safety is worth the added conceptual & implementation complexity.
"requires service S" means >= 1 implementations of S required.

"requires optional service S" means >= 0 implementations of S required.

I don't think it's too hard from a conceptual point of view.

I do agree than in many cases it will be the latter usage but, at least 
for the JDK, that is because there is a default implementation.

>
> My point is that the providing modules could be added to the 
> configuration in other ways. For example:
>
> module jaxp {
>   exports javax.xml.parsers;
> }
> module xerces {
>   requires jaxp;
>   provides service javax.xml.parsers.SAXParserFactory with ...;
> }
> module saxon {
>   requires jaxp;
>   provides service javax.xml.parsers.SAXParserFactory with ...;
> }
> module my.corp.wsparser {
>   requires jaxp;
> }
> package my.corp.wsparser;
> class Parser {
>   void parse(my.corp.WebServiceInput input) {
>     SAXParser = SAXParserFactory.newInstance().newSAXParser();
>     // ...
>   }
> }
> module my.corp.app {
>   requires my.corp.wsparser;
>   requires saxon; // I have tested with this
> }
>
> Here the call to SAXParserFactory.newInstance() would succeed so long 
> as the application ultimately includes some XML parser, without the 
> need for any "requires service javax.xml.parsers.SAXParserFactory" 
> declaration. If you forgot to include one, this would probably be 
> obvious (unless the parsing were on a rare and untested code path). 
> The application module hardcodes a particular parser implementation 
> which is known to work well, but this does not seem onerous: the 
> wsparser module could be reused with other parsers, and offering a 
> version of the app based on Xerces would be trivial. Conversely, 
> quietly substituting Xerces at installation time might well lead to a 
> host of subtle bugs.
>
> Even if you wanted to support "requires service 
> javax.xml.parsers.SAXParserFactory" for the hypothetical case of an 
> application whose author optimistically believes that any XML parser 
> would work equally well, there is no obvious reason why this 
> declaration must be in the wsparser module and not in the app module - 
> or should it be in the jaxp module which would actually be calling 
> ServiceLoader? So long as the xerces and/or saxon modules are 
> *somewhere* in the configuration, it should not matter which module(s) 
> requested the service: the "provides service ..." declarations suffice 
> for the module system to create an index of service -> providers, 
> maintained during installation.
I'm not sure that this will scale as my.corp.app may not know about all 
usages of ServiceLoader.

However I do agree that a preferred implementation, or "I have tested 
with this" as you put it, it worth discussion from a predictability 
point of view. There isn't anything in Jigsaw for this at present 
although in the JDK we have examples where there is a means to override 
or specify the provider implementation to use.

-Alan