Why do some APIs (like JCE, JSSE, etc) provide their configurable properties through singleton maps?

For example:

Security.setProperty("ocsp.enable", "true");

And this is used only when a CertPathValidator is used. I see two options for imporement:

• 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)

Some reasons might 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 casting.

I'm curious, because these properties are not always in the most visible place, and instead of seeing them while using the API, you have to go though dozens of g开发者_开发技巧oogle results before (if lucky) getting them. Because - in the first place - you don't always know what exactly you are looking for.

Another fatal drawback I just observed is that this is not thread-safe. For example if two threads want to check a revocation via ocsp, they have to set the ocsp.responderURL property.. and perhaps override the settings of each other.

This is actually a great question that forces you to think about design decisions you may have made in the past. Thanks for asking a question that should have occurred to me years ago!

It sounds like the objection is not so much the singleton aspect of this (although an entirely different discussion could occur about that) - but the use of string keys.

I've worked on APIs that used this sort of scheme, and the reasons you outline above were definitely the driving factors - it makes it crazy simple to parse a command line or properties file, and it allows for 3rd party extensibility without impact to the official API.

In our library, we actually had a class with a bunch of static final String entries for each of the official parameters. This gave us the best of both worlds - the developer could still use code completion where it made sense to do so. It also becomes possible to construct hierarchies of related settings using inner classes.

All that said, I think that the first reason (easy parsing of command line) doesn't really cut it. Creating a reflection driven mechanism for pushing settings into a bunch of setters would be fairly easy, and it would prevent the cruft of String->object transformation from drifting into the main application classes.

Extensibility is a bit trickier, but I think it could still be handled using a reflection driven system. The idea would be to have the main configuration object (the one with all the setters in it) also have a registerExtensionConfiguration(xxx) method. A standard notation (probably dot separated) could be used to dive into the resultant acyclic graph of configuration objects to determine where the setter should be called.

The advantage of the above approach is that it puts all of the command line argument/properties file parsing exception handling in one place. There isn't a risk of a mis-formatted argument floating around for weeks before it gets hit.