A DESCRIPTION OF THE REQUEST :
The Jar file specification includes a definition of how service providers
are to bindle their implementations within the confines of a Jar file.
It then proceeds to give the following example code for detecting
service provider implementations:

<code>
CharEncoder getEncoder(String encodingName) {
       Iterator ps = Service.providers(CharCodec.class);
       while (ps.hasNext()) {
           CharCodec cc = (CharCodec)ps.next();
           CharEncoder ce = cc.getEncoder(encodingName);
           if (ce != null)
               return ce;
       }
       return null;
   }
</code>

The "Service" class used in this example does not exist in the base
API.  This RFE requests that a programmatic interface - such as that
provided by the ethereal Service class - be integrated into the code
JDK in the java.util.jar package.

JUSTIFICATION :
This part of the Jar specification does not have a programmatic
implementation and is currently left up to the developers.  Since
developers have no real freedom in how they adhere to the specification,
an implementation should be provided to reduce code duplication.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
At a bare minimum:

/**
 * @return list of fully qualified service provider class names
 * which implement the specified interface.
 */
public static List<String> Service.getProviders(Class spiClass);

possibly expanding to something like the following, though how
classes which are not found (and therefore cannot be resolved
to Classes) would be handled is up in the air:

/**
 * @return list of service provider class definitions which implement
 * the specified interface.
 */
public static List<Class> Service.getProviders(Class spiClass);




CUSTOMER SUBMITTED WORKAROUND :
Reimplement this functionality everywhere we go.
Posted Date : 2005-08-03 08:47:23.0

JSR 199, the compiler/tool API, provides javax.tools.ToolProvider
which exposes some of the functionality of sun.misc.Service.

N/A