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?
