The JAR file format was extended in JDK 1.3 to support a standard way of
specifying pluggable "service providers" in a special META-INF file (see
http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#Service%20Provider for
details).  Many subsystems in the platform now use this feature, including
sound, security, networking, naming, new I/O, image I/O, printing, input
methods, and XML.  Most (though not all) of these subsystems use the internal
sun.misc.Service class, which defines a simple mechanism for looking up
services and instantiating providers.

We should refine the sun.misc.Service class as needed and then promote it into
the java.util package.  This will make it easier for both internal and external
developers to make use of the META-INF/services feature, which has become very
widely used.

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

Under development for Mustang.
Posted Date : 2005-09-08 19:42:11.0

Integrated for Mustang b57.
Posted Date : 2005-10-11 04:15:35.0

PLEASE, make this a part of the standard API! It is basically 
useless otherwise, as every implementation of this can have 
whatever interface they wish for FINDING service providers! 
That negates the use of even having this as a part of the 
spec.

Why not use this with Swing PLaF?

Perhaps a more orthogonal approach is to group it with the 
java.lang.Package class, or to create a new package of 
clases dealing exclusively with the JAR meta-inf directory.

javax.imageio.spi.ServiceRegistry can be used to perform
service provider lookups (for any service, not just Image
I/O).  I would consider this RFE satisfied if
ServiceRegistry were simply "moved" to java.util or
java.util.jar (in the same sense KeyStroke was "moved" from
javax.swing to java.awt using backward-compatible inheritance).

My votes are alread used for other RFE. Hope a positive comments may count be considered as some kind of vote. At the very least, I would like to see sun.misc.ServiceConfigurationError replaced by some kind of Exception documented in javax.imageio.spi.ServiceRegistry.lookupProvider, so we can catch it in a more reliable way (we want a way to avoid stopping the application when a service is not available).

See also:

JSR 277: Java Module System
http://www.jcp.org/en/jsr/detail?id=277

OSGi
http://www.aqute.biz/osgi.html