Why is there so much XML in Java these days?

Question

This is really more of a philosophy/design issue.

I did some work in Java back in the middle 90's and again in the early 2000's and now I'm coming back to it after spending a lot of time in C/C++ and it seems like there was an explosion of XML dependency while I was gone.

Major build system tools like ant and maven depend on XML for their configuration, but I'm actually more concerned with all the frameworks, such as Spring, Hibernate, etc. My experience is that powerful supporting libraries like these are where a developer can really get leverage for building programs with lots of features without writing a lot of code, but it really seems like I'm getting one language for the price of two here.

I write a bunch of Java classes, but then I also write a bunch of XML files to glue them together. The things that get done in the XML are things that I can see reasonable ways of doing in straight code without the middleman, and they don't really seem to be treated exactly like configuration files: they change rarely and they end up getting committed to source code control like the Java code itself, but they are distributed with the resulting application and need to be unpacked and installed in the classpath in order to get the application to work. I'm working with server applications that are not web-based, so maybe the domain is a bit different from what most people are doing, but I just can't help feeling that I must be doing something wrong here.

Can someone point me to a good source of information for why these design choices were made and what problems they are meant to solve so that I can analyze my own experiences in this context?

EDIT: I want to emphasize (as suggested by Bert F) that I'm looking for online documentation, blog entries, etc. where the designers discuss the rationale behind the choice of XML. One particular pattern that I am interested in understanding is the use of Spring beans where I would expect to see Singleton classes.

Answer 1

all the frameworks, such as Spring, Hibernate, etc.

Um, actually, all those frameworks have been mostly replacing the use of XML configuration files with annotations ever since Java 1.5 came out.

Answer 2

• xml is a standard, supported by tools and known by everyone
• most xml configurations are here because they are part of legacy applications that were created before alternatives (annotations) were added.
• most configurations in most frameworks are now available through annotations
• sometimes it is appropriate to use xml to map/configure 3rd party classes
• it is sometimes considered that having all configurations in one place is better than having them scattered
• xml is actually developer-friendly if you utilize XSD auto-complete
• new frameworks tend to ignore xml configurations (Weld (CDI) for example)

(See also this question)

Answer 3

Can someone point me to a good source of information for why these design choices were made and what problems they are meant to solve so that I can analyze my own experiences in this context?

Pure speculation, but

• The goal of some frameworks, such as Spring or Hibernate, is to transparently provide dependency injection or object-relational mapping without having to heavily modify your original source code, you should still be able to run code that is used in a Spring or Hibernate environment outside of the environment / server / etc itself (hence the emphasis on developing POJOs or "beans")
• Therefore, a method to provide/store/specify these configuration details outside of the source code itself was needed
• XML is a lot easier to parse, structure, validate, and understand than simple plain text configuration

And there you have it.

Answer 4

In the C/C++ world, there are also non-compilable source code artifacts:

• Makefile
• .pro file if you're working with Qt
• .ini files
• arbitrary .conf & .cfg files that I've seen
• various ways of defining ODBC connections

While I hate to see yet another XML deployment descriptor document in the java world, and they do appear to be decreasing since the heydays of XDoclet, at least the XML formats are consistent.

Answer 5

It is easy to represent tree data structure in XML hence other configuration types like .ini, .properties, makefile, etc. are getting replaced with XML data structure.

Answer 6

I guess the main reason is, that one cannot access mySQL databases directly from JS ...

and it's easy to generate XML dynamically - even possible to pass query parameters ;)

Answer 7

Because people are stupid. A program needed 100 lines of code in java. It is too much work. So a framework is invented to bring it down to 10 lines of java. Hooray, progress! Nobody seems to mind the additional 200 lines in XML.

Programming is tedious. Whatever makes people feel better goes a long way, even if it's a blatant lie.

Answer 8

XML is basically a glorified properties file when used in this way. The current trend is to move away from property files (and XML) as the information usually is easier to maintain when placed in the source files themselves.

"Annotations" have proven to be a very useful and productive way of providing the meta data in the source itself instead of in an external configuration file.

Answer 9

When XML was "invented", there were no best practices where is or isn't XML useful.

In the Java world the tool vendors seem always producing the absolute generic platforms, that can by the way solve the original problems with a lot of others. For this reason XML-based configuration seemed a nice idea. After some years and major projects it can be seen that this is not the way to go.

Now we see that some config files cause additional inconveniences, so try to use other solutions for these case. As several answers mentioned it, a possible replacement is the use of annotations. The biggest problem with this solution is that currently there is no tooling support for listing the required annotations. And if some annotations will become mandatory, the whole problem space is not solved.

So I believe, it is recommended either to reduce the frameworks in scope, so the configuration information has not be set explicitly for even the simple cases, or to find a way to describe external parameters in a way to provide dependency injection and its collegues to achieve both maintainability, testability and easy code writing.