OK,

So I was recently on a project where deployment of the database connection information became a concern because they were in properties and loaded by a ResourceBundle. There’s no one reason I could find to use one over the other and I think at this point time, strictly a design time decision. Obviously certain things will be deprecated over time, but below I provide sort of a pros and cons for each component.

ResourceBundles
Pros:

• lightweight file readers
• More of use when a lot of localization must occur for one’s application – extremely useful when the programmer has more control of the application and its deployment.
• Useful for backporting to previous JDKs
• Programmer has a lot more control
• Maintenance of code-drop once to the customer, provided no settings change between drops, the customer does not have to modify the properties files

Cons:

• If deploying there tends to be issues on where the properties file can exist, how the class loader loads those files for usage in code, how the systems administrator modifies those files in case of changes, etc.
• Properties files can become corrupted. Question becomes “How does one maintain that persistence store so it does not become corrupted?”
• Properties files do not scale well at all.
• Properties files are strictly name/value string pairs and provide no capability to datatype them

JNDI API
Pros:

• Easier to develop to
• Easier to maintain from a systems administration point of view
• Harder for the programmer to programmatically modify the settings from the application perspective.
• Useful for backporting applications to previous JDKs

Cons:

• Heavyweight – very large consisting of 5 packages and 83 classes.
• Provides no policy as to where in directory name space the preference data should be stored, or in which name space

Preferences API
Pros:

• Back-end Neutral
• Policy and Data Driven
• Provides “atomic-like” updates to preferences
• Is the API that will be used in future JDKs from 1.4 on
• Has a backing store capability in case of failures

Cons:

• Is not a substitute for database, for like guarantees of transactional capabilities
• Is not backward compatible to JDKs to JDKs under 1.4 but then again if you’re using 1.4 you’ve already got one foot in the tar pit.

While it’s simply a comparison, it really boils down to how the application is controlled, deployed and maintained. There is no one way better than the other that I can see other than the potential deprecation issues of the old APIs in the future. I’d definitely be interested in seeing what other developers and architects are doing. Just because it’s old doesn’t mean it isn’t a useful or even better API.

:Vaughn

Tags: information, time, concern, loader, application, Vaughn ResourceBundles, customer, Useful, space