This is a very common pattern in the Java World (but I guess it will be present in any language that needs compilation):

You want to make changes to you application, and you want to see the result of those changes immediately, you need ZeroTurnaround:

* Change the connection string to the database
* Change navigation logic
* Change the mapping of your objects to you database tables
* Change/Fix your database queries
* Change the layout of you user interface

You know you can do any of that without XML but, for JavaEnterpriseEdition servers  any recompiling, and redeploying automatically means memory leaks (''until we get a MultitaskingVirtualMachine there is no way to escape from this''), and in many cases a lot of wasted time without answering to client requests.  So, what do you do? You put all that in an XML file! That way, you will not need to redeploy or waste time recompiling, all you have to do is go, change the XML file, and you change will be available for you users instantly. Now imagine for an instant that Java had and option to "tag" a class as interpreted and automatically and instantly reloadable on change a (an @Interpreted annotation if you like), with that option if you:

* Need a single place to put your connection string? use the SingletonPattern?
* Need to abstract away the navigation logic? use container / StrategyPattern?
* Need to change the mapping of your objects to you database tables? JustDoIt, directly in your .java file
* Need to Change/Fix your database queries? Just do it,  directly in your .java file.
* Need change the layout of you user interface? Just do it, directly in your .java file.

This would improve readability, instantly add support for the debugger inside your abstracted away navigation logic, and reduce the learning curve (no need to learn custom XML schemas for this and for that, just use your Java API), "configuration files" would instantly get static checking and become "refactoring aware". It would just be a win win situation!

Want to continue using XML? use it for what it is for, information exchange, not storage of configuration information (or even worse, representation of algorithmic logic, as in JavaServerFaces navigation).

----

XML files take time to load and parse.
Just putting lots of stuff in XML files doesn't necessarily give you ZeroTurnaround.
Certainly there are plenty of systems with configuration data in XML and properties files that require a restart in order to pick up and use changes to these files.

And there are ways of updating Java code in a process without restarting the process.
There are ClassLoader approaches, and even DynamicBytecodeInstrumentation, as an option.
-- JeffGrigg

''Yes, just the kind of thing we need to convince those PHP and Ruby developers, all they have to do is get a PhD in DynamicBytecodeInstrumentation and they will get the same behavior they already have in their ZeroTurnaround by default languages ... '' In other words, unless it can be enabled easily it is as if it were not there....