FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
The new class java.util.Service is misnamed according to its own javadoc.

The javadoc has parts copied from the jar file specification ( http://download.java.net/jdk6/docs/guide/jar/jar.html ) and hence both define "A service is a well-known set of interfaces and (usually abstract) classes. A service provider is a specific implementation of a service. "

Each service has a single class or interface through which access to the service is bootstrapped, likewise for the providers. I follow the convention used in java.util.Service of calling these bootstrap classes the service and service provider respectively. (ignoring the other classes and interfaces making up the service's API)

The java.util.Service class therefore does not model a Service as defined, but models the set of available service providers for a particular service, that particular service is represented by the Type Parameter of java.util.Service.

Therefore to call java.util.Service "Service" is wrong. A better name (IMHO) would be ServiceProviders. (plural to represent a collection - but not a java.util.Collection).

Additionally it might be a good idea to change the name of the type parameter to S because that is the "Service" as defined by the jar spec and Service's javadoc.

(note that the type parameter is not javadocced either and should be, but I guess thats a bit hard when T is the service's type ).

I am imagining that in the future there may be annotations to tag services and service providers with an accompanying (JSR-269) annotation processor which generates the META-INF/services/* file, and checks that each service provider does in fact supply a public no args constructor. Ideally the annotation to tag the service ought to be called Service, but at the moment java.util.Service is polluting the name space by misappropriating the "Service" name.


Need more convincing?

Generic declarations can often be read by using the word "of" between the raw type and parameters. for example

List<String> "list of string"
Class<Integer> "class of Integer"

however
Service<MyService> "service of MyService" is not a good description

whereas with the suggested renaming

ServiceProviders<MyService> "service providers of MyService" does describe what this type is.

Need more convincing?

Compare the following two pieces of example code (taken from the class's javadocs)

first as at present:

private static Service<CodecSet> codecSetService
     = Service.lookup(CodecSet.class);

 public static Encoder lookupEncoder(String encodingName) {
     for (CodecSet cp : codecSetService) {
         Encoder enc = cp.getEncoder(encodingName);
         if (enc != null)
             return enc;
     }
     return null;
 }


next as it would be with the suggested renaming

private static ServiceProviders<CodecSet> codecSetProviders
     = ServiceProviders.lookup(CodecSet.class);

 public static Encoder lookupEncoder(String encodingName) {
     for (CodecSet cp : codecSetProviders) {
         Encoder enc = cp.getEncoder(encodingName);
         if (enc != null)
             return enc;
     }
     return null;
 }


I would assert that the names used in the second example mean that the code is more readable and the names more correctly reflect what is being modelled here.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
None, once namespace pollution occurs, it is impossible to rectify in the future without breaking backward compatibility.