RFE: Add methods to load and unload service providers at runtime

This is a copy of 4666881.
CCC request for 4666881 was withdrawn for unknown reason and cannot be re-opened.

Old description:

Name: fb126949 Date: 04/11/2002


Currently, the Java Sound implementation does not provide methods to selectively disable service providers (like file readers/writers, mixers). Currently, it re-reads the entire list of service providers at each query for a service provider, which is very inefficient both in terms of time and memory management. Furthermore, it is impossible to integrate a service provider in an applet, which is considered a crucial feature.

The fix consists of adding 2 class, e.g. javax.sound.midi.Providers and javax.sound.sampled.Providers which allow access to the list of installed service providers, register new ones by way of providing a class name or a jar file, and refresh the installed providers (e.g. if the file on disk is known to be changed).

These methods could provide the features:
/** given the spi class name, returns list of
  * implementation classes.
  * spiName is e.g. javax.sound.sampled.spi.MixerProvider
  */
Class[] Providers.getProviders(String spiName);

/**
 * disables this provider class to be used. It will be
 * unavailable until it is enabled with registerProvider.
 */
void Providers.unregister(Class clazz)

/**
 * Adds the provider class to the list
 * of providers in the given spi class. Throws an
 * exception if spi class is not valid.
 */
void register(String spiName, Class clazz)

/*
 * Adds the providers contained in the given
 * jar file.
 * Throws an exception if it does not contain
 * Java Sound service providers
 */
void register(File/InputStream/URL jarFile)

/**
 * updates the internal list of providers
 * [for the given spi class].
 */
void refresh( [String spiName] )

There is some room for discussion:
- name of class: "Providers" ?
- should it be possible to register a provider in form of an instantiated object ?
- would it be useful to have a getProviders(jarfile) method ?
- security issues ?
- is there anything that may break compatibility ? The only differences to the current implementation that I can see are:
  1) at runtime, newly added jar files to the CLASSPATH will not be recognized unless refresh is called. The current implementation scans the entire classpath for each call to e.g. AudioSystem.getMixerInfo()
  2) at start-up, also applets will load the service providers from the classpath (currently, they only load providers from local file systems)



======================================================================


###@###.### 2002-04-25
Further reflection leads to the conclusion that these methods should not be in one class for midi and sampled, but they should be duplicated in MidiSystem and AudioSystem.



###@###.### 2002-10-15
The Image IO API has classes/methods for loading/unloading service providers at runtime: see e.g.
javax.imageio.spi.ServiceRegistry
javax.imageio.spi.IIORegistry
javax.imageio.ImageIO


###@###.### 2002-10-15
Edited the description text to incorporate JDC comments and further ideas.
CCC rejected duplication of the classes in sampled and midi packages