Each provider has a name and a version number, and is configured in each runtime it is installed in.
See The Provider Class in the "Java Cryptography Architecture API Specification & Reference" for information about how a particular type of provider, the cryptographic service provider, works and is installed. However, please note that a provider can be used to implement any security service in Java that uses a pluggable architecture with a choice of implementations that fit underneath.
Some provider implementations may encounter unrecoverable internal errors during their operation, for example a failure to communicate with a security token. A ProviderException should be used to indicate such errors.
The service type Provider is reserved for use by the
security framework. Services of this type cannot be added, removed,
or modified by applications.
The following attributes are automatically placed in each Provider object:
| Name | Value |
|---|---|
Provider.id name |
String.valueOf(provider.getName()) |
Provider.id version |
String.valueOf(provider.getVersion()) |
Provider.id info |
String.valueOf(provider.getInfo()) |
Provider.id className |
provider.getClass().getName() |
First, if there is a security manager, its
checkSecurityAccess method is called with the string
"clearProviderProperties."+name (where name
is the provider name) to see if it's ok to clear this provider.
If the default implementation of checkSecurityAccess
is used (that is, that method is not overriden), then this results in
a call to the security manager's checkPermission method
with a SecurityPermission("clearProviderProperties."+name)
permission.
containsKey
method.Note that this method is identical in functionality to containsValue, (which is part of the Map interface in the collections framework).
Note that this method is identical in functionality to contains (which predates the Map interface).
null if the property is not found.The XML document must have the following DOCTYPE declaration:
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">Furthermore, the document must satisfy the properties DTD described above.
The specified stream remains open after this method returns.
wait methods.
The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:
synchronized statement
that synchronizes on the object.
Class, by executing a
synchronized static method of that class.
Only one thread at a time can own an object's monitor.
wait methods.
The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.
key property to have the specified
value.
First, if there is a security manager, its
checkSecurityAccess method is called with the string
"putProviderProperty."+name, where name is the
provider name, to see if it's ok to set this provider's property values.
If the default implementation of checkSecurityAccess
is used (that is, that method is not overriden), then this results in
a call to the security manager's checkPermission method
with a SecurityPermission("putProviderProperty."+name)
permission.
key property (and its corresponding
value).
First, if there is a security manager, its
checkSecurityAccess method is called with the string
"removeProviderProperty."+name, where name is
the provider name, to see if it's ok to remove this provider's
properties. If the default implementation of
checkSecurityAccess is used (that is, that method is not
overriden), then this results in a call to the security manager's
checkPermission method with a
SecurityPermission("removeProviderProperty."+name)
permission.
store(OutputStream out, String comments) method
and suppresses IOExceptions that were thrown.put. Provided for
parallelism with the getProperty method. Enforces use of
strings for property keys and values. The value returned is the
result of the Hashtable call to put.Properties table to the output stream in a format suitable
for loading into a Properties table using the
load
method.
The stream is written using the ISO 8859-1 character encoding.
Properties from the defaults table of this Properties
table (if any) are not written out by this method.
If the comments argument is not null, then an ASCII #
character, the comments string, and a line separator are first written
to the output stream. Thus, the comments can serve as an
identifying comment.
Next, a comment line is always written, consisting of an ASCII
# character, the current date and time (as if produced
by the toString method of Date for the
current time), and a line separator as generated by the Writer.
Then every entry in this Properties table is
written out, one per line. For each entry the key string is
written, then an ASCII =, then the associated
element string. Each character of the key and element strings
is examined to see whether it should be rendered as an escape
sequence. The ASCII characters \, tab, form feed,
newline, and carriage return are written as \\,
\t, \f \n, and
\r, respectively. Characters less than
\u0020 and characters greater than
\u007E are written as
\uxxxx for the appropriate hexadecimal
value xxxx. For the key, all space characters are
written with a preceding \ character. For the
element, leading space characters, but not embedded or trailing
space characters, are written with a preceding \
character. The key and element characters #,
!, =, and : are written
with a preceding backslash to ensure that they are properly loaded.
After the entries have been written, the output stream is flushed. The output stream remains open after this method returns.
An invocation of this method of the form props.storeToXML(os, comment) behaves in exactly the same way as the invocation props.storeToXML(os, comment, "UTF-8");.
The XML document will have the following DOCTYPE declaration:
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
If the specified comment is null then no comment
will be stored in the document.
The specified stream remains open after this method returns.
The current thread must own this object's monitor. The thread
releases ownership of this monitor and waits until another thread
notifies threads waiting on this object's monitor to wake up
either through a call to the notify method or the
notifyAll method. The thread then waits until it can
re-obtain ownership of the monitor and resumes execution.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.The current thread must own this object's monitor.
This method causes the current thread (call it T) to place itself in the wait set for this object and then to relinquish any and all synchronization claims on this object. Thread T becomes disabled for thread scheduling purposes and lies dormant until one of four things happens:
A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout);
... // Perform action appropriate to condition
}
(For more information on this topic, see Section 3.2.3 in Doug Lea's
"Concurrent Programming in Java (Second Edition)" (Addison-Wesley,
2000), or Item 50 in Joshua Bloch's "Effective Java Programming
Language Guide" (Addison-Wesley, 2001).
If the current thread is interrupted by another thread while it is waiting, then an InterruptedException is thrown. This exception is not thrown until the lock status of this object has been restored as described above.
Note that the wait method, as it places the current thread into the wait set for this object, unlocks only this object; any other objects on which the current thread may be synchronized remain locked while the thread waits.
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.
This method is similar to the wait method of one
argument, but it allows finer control over the amount of time to
wait for a notification before giving up. The amount of real time,
measured in nanoseconds, is given by:
1000000*timeout+nanos
In all other respects, this method does the same thing as the method of one argument. In particular, wait(0, 0) means the same thing as wait(0).
The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until either of the following two conditions has occurred:
notify method
or the notifyAll method.
timeout
milliseconds plus nanos nanoseconds arguments, has
elapsed.
The thread then waits until it can re-obtain ownership of the monitor and resumes execution.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout, nanos);
... // Perform action appropriate to condition
}
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.