I'm currently working on a project which leverages the Springframework. We are using the container to manage dependencies, Dynamic Modules to leverage OSGi and a lot of other stuff which sometimes makes life easier. Spring's default configuration option is XML. So if you want the Spring container to know about your class you'd write something like the following:
<bean id="person" class="de.linsin.sample.spring.contracts.PersonImpl"/>
Of course that's not the whole story, there's lot's of namespace configuration and all the other XML stuff in your configuration file. Basically every class you want Spring to know about, needs a complement in your configuration. It quickly gets more and more, e.g. if you add transaction management or logging. In short: your XML configuration virtually outgrows!
I said this before, but here it is again: I like Spring's XML configuration and I believe it's all a question of proper tooling. If you have a tool like IntelliJ IDEA, it's a lot easier to handle your Spring configuration.
There's another configuration notation, which has been around for a while: properties files. They contain simple key value pairs:
In my last project, we used properties files excessively to configure global variables, which are set at startup of the Java EE container for the lifetime of the JVM. Properties files are also the standard way of internationalizing your application. For each language you can provide a file which contains keys that are used throughout your application and values, containing the translated messages. The keys are being substituted at runtime with the appropriate values, depending on the currently chosen language. As with XML, there is no compiler warning or static check, which could tell you that you haven't configured your properties file correctly. It's generally a good idea to add a null check before accessing a property, since it can lead to nasty NPEs if it's undefined. In my opinion readability of properties files can't keep up with XML. Usually your files are sprinkled with comments, which indicate where and how the properties are used. That doesn't really scale and comments are not always the best way of enforcing a contract.
Another problem with properties files is encoding. As soon as they contain none Latin-1 characters, you need to do extra work more work to avoid problems. Usually you shouldn't have those encoding problems with XML. Proper tooling is a real problem when it comes to management of properties files. I haven't found a really good tool, which conducts some kind of check if my code and properties files are in-sync. I have to plug IntelliJ again here. They are doing a somewhat reasonable job of managing your properties.
One of the most exotic configuration notation, at least in my opinion, is JSON. Yes, I know! You are probably raising your eyebrows right now, like I did the first time I read about it. JSON is used as the configuration notation of SpringSource's Application Platform - S2AP. You can among other stuff configure logging using JSON:
"com.foo.*" : "verbose",
"com.foo.UnimportantClass" : "info",
"com.bar.ImportantClass" : "verbose"
Comparing these different configuration notations rather subjectively, there is no clear winner for me. The only real difference is proliferation. Despite its somewhat bad reputation, XML is clearly the most widely used configuration notation, directly followed by properties files. JSON is kind of the "new kid on the block", because I've never seen it being used for configuration, before S2AP.
Besides its wide usage and ubiquity, XML has DTD and namespaces, which I believe can eliminate the two major downsides: verboseness and misconfiguration. The strong tool support, which came with the proliferation, can help to handle spelling errors and management of large numbers of XML files. I think working with XML can be quite painless today, if you have the right tools.