I'm a newbie when it comes to properties, and I read that XML is the preferred way to store these. I noticed however, that writing a regular .properties file in the style of
foo=bar
fu=baz
also works. This would mean a lot less typing (and maybe easier to read and more efficient as well). So what are the benefits of using an XML file?
If you have alot of repeating data, it can be simpler to process
<connections> <connection>this</connection> <connection>that</connection> <connection>the other</connection> </connections>
than it is to process
connection1=this connection2=that connection3=the other
especially if you are expecting to have to store ALOT of data, or it must be stored in a definite hierarchy
If you are just storing a few scalar values though, I'd go for the simple Properties approach every time
In XML you can store more complex (e.g. hierarchical) data than in a properties file. So it depends on your usecase. If you just want to store a small number of direct properties a properties file is easier to handle (though the Java properties class can read XML based properties, too).
It would make sense to keep your configuration interface as generic as possible anyway, so you have no problem to switch to another representation ( e.g. by using Apache Commons Configuration ) if you need to.
XML is handy for complex data structures and or relationships. It does a decent job for having a "common language" between systems.
However, xml comes at a cost. Its is heavy to consume. You've got to load a parser, ensure the file is in the correct format, find the information etc...
Whereas properties files is pretty light weight and easy to read. Works for simple key/value pairs.
It depends on the data you're encoding. With XML, you can define a more complex representation of the configuration data in your application. Take something like the struts framework as an example. Within the framework you have a number of Action classes that can contain 1...n number of forward branches. With an XML configuration file, you can define it like:
<action class="MyActionClass">
<forward name="prev" targetAction="..."/>
<forward name="next" targetAction="..."/>
<forward name="help" targetAction="..."/>
</action>
This kind of association is difficult to accomplish using just the key-value pair representation of the properties file. Most likely, you would need to come up with a delimiting character and then include all of the forward actions on a single property separated by this delimiting character. It's quite a bit of work for a hackish solution.
Yet, as you pointed out, the XML syntax can become a burden if you just want to state something very simple, like set feature blah to true.
The biggest benefit to using an XML file is that XML declares its encoding, while .properties does not.
If you are translating these properties files to N languages, it is possible that these files could come back in N different encodings. And if you're not careful, you or someone else could irreversibly corrupt the character encodings.
If you have lots of data with duplicate namespaces, xml is the one for you:
I once had a colleague that told me that a properties file can do 97% of what an xml file does. Sure xml files have attributes (like leaves of a branch) but an xml source by the name of w3schools recommends only use of attributes as meta-data to describe the xml tag itself: for instance, the "id" attr.
So, I suppose the extra 3% comes from a forced "integrity" constraint on the relationship of data with the same namespace, using a spatial relationship more openly apparent in xml. For example,
a.b=The Joker a.b.c.=Batgirl a.b=Batman a.b=Superman a.b.c=Supergirl
Using properties, there is no constraint relationships like xml (for ex: alike superheroes or originals)
[a] [b]Batman[/b] [b]Superman[/b] [a]
[a] [b]Batman[/b] [b] [c]Batgirl[/c] [/b] [/a]
The difference in xml.... http://ilupper.blogspot.com/2010/05/xml-vs-properties.html