Dump services webrev

[Paul Sandoz]

On May 25, 2012, at 7:43 PM, Alan Bateman wrote:
>> 
>> Same in NetBeans; logs a warning and continues with no impact on the caller. Catching ServiceConfigurationError in each caller would be be a pain, and since it is unchecked it would be easily forgotten, and if forgotten it is unlikely to be noticed during development and come up only in production systems. In Jigsaw the module system should catch most potential problems (e.g. misspelled service name) statically, but the service constructor/factory could still throw an exception I suppose.
> For Java SE then many APIs specify if/how fail if the instantiation of the provider fails. Exactly how they fail is a bit inconsistent. As examples JAXP defines various *ConfigurationExceptions, NIO is more low level and will throw an unspecified error, and there are others. So I think the right thing it to leave it up to the caller to specify how it behaves in this case, meaning I don't think ServiceLoader should use logging or emit warnings.
> 

There is a distinction between a service *factory* and a set of services all of which are relevant [*]. For the latter case a rogue service can mess up access to the subset of those that come after it (and that subset is arbitrary and could change for each execution of the VM).

I think we need some ability for the developer to control what should be done under such circumstances (e.g. some callback that decides to continue or re-throw). This is a good use-case for ModuleServiceProvider.

Paul.

[*] This was very common in Jersey hence the support to ignore. One reason why this was required is because developers would often forget to include, on the classpath, the additional dependencies for their component. So hooray for modules! (as long as there are no "requires optional" stuff causing runtime issues).