Using the Provider Class
putAlg.Alias.MessageDigest.SHA−1, SHA; }
public static final synchronized void verifyForJCE { See Appendix E for more details
throw new SecurityExceptionCant verify for JCE; }
}
The only properties a provider is required to put into its property list are the properties that match the engine name and algorithm pair with the class that implements that operation. In this example, thats handled with the
first four calls to the put
method but remember too that the provider can implement as few or as many operations as it wants to; it neednt implement more than a single engine with one algorithm, or it can
implement dozens of enginealgorithm pairs. Note that the class name is the fully qualified package name of the class.
The provider also has the opportunity to set any other properties that it wants to use. If the provider wants to set aliases as weve done with the final call to the
put method, its free to do so. The last code line of
our example shows the syntax to do this; it means that the string SHA−1 can be used instead of the string SHA when searching for a message digest class.
A provider can set any other arbitrary properties that it wants as well. For instance, a provider class could set this property:
putNativeImplementation, false;
if it wanted the classes that use the provider to be able to determine if this particular XYZ implementation uses native methods.
[1]
It can also use the convention that certain properties are preceded with the word Alg
and contain the algorithm name, like this:
[1]
RSA algorithms sometimes use native methods because there are existing implementations of them that are written in C and have gone through an extensive quality acceptance test that
many commercial sites have a level of confidence in. However, as Java has become more widely used, this is now the exception.
putAlg.NativeImplementation.XYZ, false;
Theres no advantage to setting any additional properties −− nothing in the core SDK will use them. They can be set to make the classes that accompany your provider class easier to write −− for example, your
XYZSignature class might want to inquire which particular providers have a native method
implementation of the XYZ algorithm. Whatever information you put into your provider and how your accompanying classes use that information is a design detail that is completely up to you. The
Security class will help you manage the information in these properties; this relationship to the
Security class is the
reason we used a string value for the NativeImplementation
property rather than a Boolean
value. Theres one more nonpublic method of the
Provider class that is used by the security API:
static Provider loadProviderString className Instantiate a provider that has as its type the given class. This method is provided mostly for
convenience −− it simply loads the given class and instantiates it. However, this method also ensures that the loaded class is an instance of the
Provider class.
This method creates an instance of a provider. The importance of this method stems from how it performs its task: it creates the instance of the provider object by calling the
newInstance method of the
Class class. In order for that operation to succeed, the provider class must therefore have a default constructor −−
that is, a constructor that requires no arguments. This is why in our example we provided such a constructor and had the constructor hardwire the name, version number, and information string. We could have provided
an additional constructor that accepts those values as parameters, but it would never be called since the only way in which the virtual machine uses providers is to load them via this method.