If a developer has used the Java security APIs he already knows what’s ahead. That’s not the only example, alas, but I’ll be using it to illustrate my point.

These APIs provide their configurable properties through singleton maps. Security.setProperty("ocsp.enable", "true"); for example

The documentation of these properties is not always in the most visible place, and instead of seeing them while using the API, you have to go though dozens of google results before (if lucky) get to them. And you don’t always know what exactly you are looking for.

Another very serious concern is thread-safety. For example if two threads want to check a revocation via ocsp, they have to set the ocsp.responderURL property in some cases. The “validate(..)” method is not thread-safe, so you should make a synchronization on the validation yourself. A synchronization (and hence potential blocking and waiting) that could have been avoided.

Some at least semi-valid reasons for such type-unsafe, thread-unsafe, Map design could be:

• setting the properties from the command line – a simple transformer from command-line to default values in the classes suggested above would be trivial
• allowing additional custom properties by different providers – they can have public Map getProviderProperties(), or even public Object ... with the casting to the custom provider class.

But since many properties are used by only one class (or just a couple), this can be made far more usable. The two potential steps for improvement are:

• again singleton, but with getter and setter for each property
• an object containing the properties relevant to the current context CertPathValidator.setValidatorProperties(..) (it already has a setter for PKIXParameters, which is a good start, but it does not include everything)

So the appeal to API designers is – don’t make properties configurable via static Maps.