"With proper markup/logic separation, a POJO data model, and a refreshing lack of XML..." So begins the introduction to one of the current crop of open source Web application frameworks on its Web site. Sadly this seems to be a common sentiment within the Java framework development community; the phrase "XML Hell" is thrown around with the same vehemence once reserved for the "DLL Hell" so characteristic of early versions of Microsoft Windows. Is this wisdom genuine or apocryphal? In this article I will examine some of the reasons why anti-XML sentiment is misguided.

The Roots of the Myth
Where does this distaste for XML in the Java framework development community come from? Several factors immediately spring to mind.

First of all, XML's lack of tooling support is a significant issue. Let's use the XML-driven framework Apache Struts as an example. Though popular, Struts is often held up as an illustration of how XML-configured frameworks are bad (although many making this claim are competitors of Struts). In reality, I think the problem has nothing to do with XML; rather it's the fact that the Struts page-flow metadata represents a series of complex relationships. Of course the raw XML that describes these relationships is hard to understand, but that's not really a problem with the XML itself. Any textual description of a page flow, in code or metadata, is hard to understand. Put that same relationship map into the form of a diagram and the problem goes away. Indeed when mainstream development environments such as Oracle JDeveloper and Eclipse started to provide visual diagramming for Struts, the framework's popularity skyrocketed. An inability to understand something often translates into dislike - perhaps XML has been the innocent bystander in a bigger battle against perceived complexity.

Overuse also adds to the negative perception of XML. While great for describing complex relationships, XML can be viewed as overkill for simple framework configuration. Enterprise JavaBeans (EJB) are often held up as an example of how badly XML can be overused. Interestingly one of the key features of the latest version of the EJB specification (3.0) addressed the issue head on. In the latest version, although XML metadata is still a valid option for describing the entities, code annotations and "configuration by exception" are the norm for describing simpler relationships. XML is only used for the corner cases.

Are Annotations the Future?
After EJB adopted annotations as a configuration option, the floodgates opened and annotations seemed to be the one true path to framework configuration. New annotation-based frameworks such as Seam were developed, and old frameworks such as Struts were hastily retrofitted in a misguided attempt to gain favor.