RFE: Add methods to load and unload service providers at runtime
11-Closed, duplicate of 6946220,
request for enhancement
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 customer ?
- 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)
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.
The Image IO API has classes/methods for loading/unloading service providers at runtime: see e.g.
Edited the description text to incorporate JDC comments and further ideas.
Posted Date : 2005-07-25 10:20:22.0
Very much needed features for supporting plugin's in applets, games, open systems.
No time for tiger. Commit to mustang.
Posted Date : 2005-07-25 10:20:22.0
Submitted On 20-APR-2002
Yes, this needs discussion.
- I would opt for type-safety, means: using either Class
objects or provider instances instead of Strings with the
names of provider classes. In the second case, perhaps a
marker interface for providers should be introduced. An
even stronger argument for not using class names is where
class loading happens: if class names are passed the
Provider class has to implement this. In this case, this
implementation decides on which classloader is used, which
is very inflexible. Currently, there is the problem that
applets can't load providers from the network. This exactely
due to this type of inflexibility, with the only way to
circumvent it setting the thread's context class loader to
the system classloader! Leaving the issue of class loading
outside of th library, but to the application is the way of
choice to get flexibility. For instance: loading classes
that never existed as a file, but only in memory, because
they were generated dynamically. Or: tieing a provider class
to a seperate class loader instance, because removing a
class loader instance is the only way in java to remove
loaded classes from the VM. Or: using classes as providers
that aren't packaged as a class file. Or dozends of other
ideas creative programmers will come up with.
- the semantics of adding the same class/instance twice
should be defined.
- conformity in method naming: either register/ungerister or
- package: some beta version of Java Sound (0.86 or 0.9) had
classes javax.sound.sampled.spi.AudioConfig and
Submitted On 25-JAN-2003
In my previous statement, I've intermixed two issues in a
way that led to misunderstandings. I'm trying to clearify
provider type arguments
They should be of type Class, not String. In the case of
'register("javax.sound.sampled.spi.MixerProvider", ...)', a
typo in the provider type (the String) is detected at
runtime. On the other hand, if it reads
...)', a typo is detected by the compiler. So this is an
issue about some sort of "type safety".
provider instance arguments
I originally opposed to just using Object as type. Using the
type of a marker interface 'Provider' (or something similar)
that is implemented by MixerProvider, MidiDeviceProvider
etc. This would give more type safety than just using
'Object'. Now, 'Class' is proposed, which I haven't thought
of before. It's clear that there should be only one instance
per (specific) service provider class. So in theory, using
'Class' has the same (intended) semantics. However, details
have to be considered. At which stage does the instantiation
of the service providers take place? It should be assured
that the implementation does not lead to an inflexibility
similar to using a hardcoded ClassLoader.
My suggestion in general: implement, then set standards!
Unless such a system is implemented and has proven to be
usable in practice, there will be flaws that we won't catch
by reasoning only.
PLEASE NOTE: JDK6 is formerly known as Project Mustang