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
