Clarification on META-INF/services from SOTMS

[Alex Buckley]

On 3/17/2016 11:49 AM, Paul Benedict wrote:
>  From section 4 on Services:
> "The module system could identify service providers by scanning module
> artifacts for META-INF/services resource entries, as the ServiceLoader
> class does today. That a module provides an implementation of a particular
> service is equally fundamental"
>
> My question regards the use of "could" -- a word that indicates
> possibility, not certainty. It's peculiar wording. If the module system
> still uses META-INF/services, then "could" is misleading.

The word "could" is setting up a strawman -- we could, technically, do 
something, but for philosophical reasons we are going to do something else.

For an explicit named module, the uses/provides clauses are dominant -- 
nothing in the document suggests that META-INF/services files in 
explicit named modules are scanned.

For an implicit named module (a.k.a. automatic module), the document 
does have a suggestion involving META-INF/services.

For the unnamed module, the document is silent on how it offers service 
providers to named modules, and whether it can discover service 
providers from named modules. Interop between the unnamed module and 
named modules is a constant source of strife.

> 1) Is META-INF/services being planned to go away in the future?

No.

> 2) What is the relationship between META-INF/services and provides/with
> keywords? Who wins in the presence of both?

Good question, which the cleanup of the ServiceLoader API spec will have 
to address.

Alex