In this lookup mechanism a service is represented by an interface or an aoqi@0: * abstract class. (A concrete class may be used, but this is not aoqi@0: * recommended.) A provider of a given service contains one or more concrete aoqi@0: * classes that extend this service class with data and code specific to aoqi@0: * the provider. This provider class will typically not be the entire aoqi@0: * provider itself but rather a proxy that contains enough information to aoqi@0: * decide whether the provider is able to satisfy a particular request together aoqi@0: * with code that can create the actual provider on demand. The details of aoqi@0: * provider classes tend to be highly service-specific; no single class or aoqi@0: * interface could possibly unify them, so no such class has been defined. The aoqi@0: * only requirement enforced here is that provider classes must have a aoqi@0: * zero-argument constructor so that they may be instantiated during lookup. aoqi@0: *
aoqi@0: *A service provider identifies itself by placing a provider-configuration aoqi@0: * file in the resource directory META-INF/services. The file's name aoqi@0: * should consist of the fully-qualified name of the abstract service class. aoqi@0: * The file should contain a list of fully-qualified concrete provider-class aoqi@0: * names, one per line. Space and tab characters surrounding each name, as aoqi@0: * well as blank lines, are ignored. The comment character is '#' aoqi@0: * (0x23); on each line all characters following the first comment aoqi@0: * character are ignored. The file must be encoded in UTF-8. aoqi@0: *
aoqi@0: *If a particular concrete provider class is named in more than one aoqi@0: * configuration file, or is named in the same configuration file more than aoqi@0: * once, then the duplicates will be ignored. The configuration file naming a aoqi@0: * particular provider need not be in the same jar file or other distribution aoqi@0: * unit as the provider itself. The provider must be accessible from the same aoqi@0: * class loader that was initially queried to locate the configuration file; aoqi@0: * note that this is not necessarily the class loader that found the file. aoqi@0: *
aoqi@0: *Example: Suppose we have a service class named aoqi@0: * java.io.spi.CharCodec. It has two abstract methods: aoqi@0: *
aoqi@0: *aoqi@0: * public abstract CharEncoder getEncoder(String encodingName); aoqi@0: * public abstract CharDecoder getDecoder(String encodingName); aoqi@0: *aoqi@0: * aoqi@0: * Each method returns an appropriate object or null if it cannot aoqi@0: * translate the given encoding. Typical CharCodec providers will aoqi@0: * support more than one encoding. aoqi@0: * aoqi@0: *
If sun.io.StandardCodec is a provider of the CharCodec aoqi@0: * service then its jar file would contain the file aoqi@0: * META-INF/services/java.io.spi.CharCodec. This file would contain aoqi@0: * the single line: aoqi@0: *
aoqi@0: *aoqi@0: * sun.io.StandardCodec # Standard codecs for the platform aoqi@0: *aoqi@0: * aoqi@0: * To locate an encoder for a given encoding name, the internal I/O code would aoqi@0: * do something like this: aoqi@0: * aoqi@0: *
aoqi@0: * CharEncoder getEncoder(String encodingName) {
aoqi@0: * for( CharCodec cc : ServiceFinder.find(CharCodec.class) ) {
aoqi@0: * CharEncoder ce = cc.getEncoder(encodingName);
aoqi@0: * if (ce != null)
aoqi@0: * return ce;
aoqi@0: * }
aoqi@0: * return null;
aoqi@0: * }
aoqi@0: *
aoqi@0: *
aoqi@0: * The provider-lookup mechanism always executes in the security context of the
aoqi@0: * caller. Trusted system code should typically invoke the methods in this
aoqi@0: * class from within a privileged security context.
aoqi@0: *
aoqi@0: * @author Mark Reinhold
aoqi@0: * @version 1.11, 03/12/19
aoqi@0: * @since 1.3
aoqi@0: */
aoqi@0: final class ServiceFinderThis method transforms the name of the given service class into a aoqi@0: * provider-configuration filename as described above and then uses the aoqi@0: * getResources method of the given class loader to find all aoqi@0: * available files with that name. These files are then read and parsed to aoqi@0: * produce a list of provider-class names. The iterator that is returned aoqi@0: * uses the given class loader to lookup and then instantiate each element aoqi@0: * of the list. aoqi@0: *
aoqi@0: *Because it is possible for extensions to be installed into a running aoqi@0: * Java virtual machine, this method may return different results each time aoqi@0: * it is invoked.
aoqi@0: *
aoqi@0: * @param service The service's abstract service class
aoqi@0: * @param loader The class loader to be used to load provider-configuration files
aoqi@0: * and instantiate provider classes, or null if the system
aoqi@0: * class loader (or, failing that the bootstrap class loader) is to
aoqi@0: * be used
aoqi@0: * @throws ServiceConfigurationError If a provider-configuration file violates the specified format
aoqi@0: * or names a provider class that cannot be found and instantiated
aoqi@0: * @see #find(Class)
aoqi@0: */
aoqi@0: static
aoqi@0: * ClassLoader cl = Thread.currentThread().getContextClassLoader();
aoqi@0: * return Service.providers(service, cl);
aoqi@0: *
aoqi@0: *
aoqi@0: * @param service The service's abstract service class
aoqi@0: *
aoqi@0: * @throws ServiceConfigurationError If a provider-configuration file violates the specified format
aoqi@0: * or names a provider class that cannot be found and instantiated
aoqi@0: * @see #find(Class, ClassLoader)
aoqi@0: */
aoqi@0: public static