#ServiceLoaderEnhancements

[Peter Levart]

Hi,

Reading number (2) of the proposal... the static provider() method 
(declared by "provider class") and returning a "provider object" sounds 
confusing when coupled with number (3) which proposes a 
ServiceLoader.Provider interface. Should Provider interface be renamed 
to ProviderFactory?

Or should rather ServiceLoader documentation be revised to stop talking 
about service providers and talk about service types(s) and service 
implementation(s) or service implmenetation classes instead? It's OK for 
a module to "provide" a service of some "service type" with some 
"service implementation class", but it is strange to call the 
implementation class a provider class and an instance of it a provider 
object. I think there's one level of indirection that is too much in the 
speak currently.

If you agree with above, then I propose the static method to simply be 
called "getInstance()" and (to make it parallel with constructor) don't 
require it to be a public method in a public class if the service is 
provided by a module. One thing that is not clear is whether the yyy in 
"provides xxx with yyy" directive of module declaration must be a 
concrete class and a subtype of service type when the service is 
obtained via a static method. For example, is the following a valid 
configuration: Service type A, implementation class B (a subtype of A), 
static method declared in C (unrelated to A) with return type B (or A or 
anything between A and B?). I think the constraints could be more easily 
understood if the method  was called getInstance() and required to have 
the same return type as the declaring class. The service implementation 
class could then be anything (perhaps a subtype of the methods's return 
type/declaring class).

The interface in (3) can then be called ServiceLoader.Provider.

What do you think?