XML-based J2EE frameworks considered harmful

Are you using one of the XML-based web frameworks such as Spring, WebWork or Struts? Then you've been duped. Conned. Flimflammed. Bamboozled. Hornswoggled. (Yes, this is a rant ;-) Here's why:

  • XML doesn't get executed, it gets read
    Unlike Java source code, XML just gets read once rather than being executed. That means that it can't respond dynamically to changes in the application environment. You are stuck with whatever is configured at the time the XML is read - usually this is at the very beginning of your applications startup processing.

  • XML doesn't have constants or variables
    Want to use the same configuration value across multiple XML files? Tough, you can't. The only way you can get even remotely near to this is to use vile preprocessing hacks.

  • XML doesn't have flow-of-control
    Want to put some conditional logic or loops in your XML? Sorry, there's no standard way of doing this. Sure, some frameworks attempt to provide this using their own custom XML entities, but every one of them does it differently.

  • XML files aren't programs
    All that good stuff you were taught in your CS classes about type safety, information hiding, coupling, cohesion and so forth? Forget it, thanks to XML you are now back in the 1960's.
  • Welcome to action at a distance
    See that attribute you set in your XML? Well, that probably has to map onto a method call on an object. Which method and which object? Prepare to spend hours pouring over the source of your framework to find out.

  • You can't garbage-collect XML
    See all that XML goop you've lovingly crafted? Well, say goodbye to large chunks of the memory on your machine. The application frameworks usually like instantiate all of the objects you might ever need at startup, because they have no way of knowing if they are ever used. And the frameworks make sure they are nailed into place, so forget about them ever being GC'd if they aren't actually used.

  • You'd better understand all about classloader leaks
    All this XML you've used requires all sorts of introspective sleight of hand by your application framework. And that involves getting it's grubby little hands into the Java runtime support mechanisms, and holding references to bits of its innards such as classloaders. And the next time you redeploy your application, all those references probably aren't going to be cleaned up properly, so say goodbye to lots of leaked memory. And if you redeploy just a few times more, expect your application to fall over completely as it runs out of memory.

  • You've defeated type checking
    Most everything in XML ends up being a text string. That includes class names, method names and method parameters. Got one of them wrong? Oops, more mysterious exceptions will be heading your way at some random point in the future.

  • Debuggers don't debug XML
    That cool debugger your IDE has? Don't bother. It doesn't work on XML files. The important bits of your application logic are now buried in some introspective labyrinth buried deep inside a library that you probably don't understand fully. Welcome instead to the world of cryptic stack traces and sleepless nights.

  • You can't run FindBugs or PMD on XML
    Those nice tools that check your source code for programming errors? Guess what? They don't work on XML. You've just thrown away another tool in your armoury.

  • You've moved bug detection to run-time
    All that wonderful checking that the Java compiler does to make sure your application is correct? Gone, javac doesn't do XML. You aren't going to know if your application is even minimally correct until you try running it - and there's a fair chance that it will run for some considerable time before you find out that you've made some simple programming error or other.

  • You still have to rebuild your application if you modify it
    XML proponents tell us that one of the major benefits of XML for configuring J2EE frameworks is that you can reconfigure your application without changing the source. Really? How? Does anyone ever change the XML files in a deployed WAR file? Of course not, that would be insane. Ah, you have to edit the source XML files then rebuild and redeploy your WAR file - Oh dear, you still would have had to do that even if you didn't use XML at all.

  • You've just doubled your troubles
    Think that Java is a big, complicated language? You 'aint seen nothing yet. Faced with a big complex application and want to figure out who is calling a method? Well, don't expect your IDE to be of any help, it doesn't understand your application framework's XML files. Trying to trace through the code and figure out what happens? Forget it. You'll go insane hopping between Java and XML source and trying to figure out which bit of opaque magic provided by your application framework is doing what, where and when.

I'm fully aware that the list above is crammed with generalisations, and that there are various hacks and workarounds for some of the issues. However the overall point I'm making is that XML isn't a programming language, yet virtually all of the major J2EE frameworks use it as if it is. The pervasive use of XML for tasks for which it is not suited has effectively discarded the last 30 years of software engineering advances. This is a huge mistake, and I expect that in 5 years time people will look back at the current XML mania and say "What the hell were we thinking of?"

Categories : Web, Tech

Re: XML-based J2EE frameworks considered harmful

If you are using Spring only for dependency injection (DI), you should consider using or at least testing Google Guice. It is an DI framework based on Java 5 annotations and completely avoids the usage of XML. This way, you will get all the benefits of type safety, compile time checking, ...

But I'm sure, that the time has come, that the Java people have a lesson learned: XML is just a good replacement for binary files and protocols, but not in any way a (source) language for programming or configuring.

Re: XML-based J2EE frameworks considered harmful

I both get your point and have to agree with a bunch of arguments in here, especially talking about rebuilding/redeploying .war files instead of "just" changing configuration. But after all, aren't we software developers, capable of doing jobs more difficult than "just" to wisely decide which tool to use and how much to make use of it? There probably are things that belong to some sort of configuration file, and there are some things that belong to code rather than configuration, I'd say. Spring+AOP+XML configuration is an incredibly powerful tool helping to keep code clean and yet keep track of how things work together... given one does it right. But in my opinion that is the very point: We should consciously decide which tool to be used for which solution, rather than blindly rely upon a "one-size-fits-all" approach. And, for that matters... Maybe we just have to make better solutions... What sort of approach instead of XML configuration would you prefer here, given not to have to mess with your code each time, say, you add/remove some AOP'ish service to it? Cheers, Kristian

Re: XML-based J2EE frameworks considered harmful

Tobias: I couldn't agree more with your last paragraph. Unfortunately I don't have the luxury of choosing a different framework. I'm working on a fairly substantial J2EE application that we are preparing to release as Open Source, trying to get it to build and run cleanly under NetBeans so that it is possible for other people to modify it easily - the current configuration and build mechanisms are arcane to say the least. I'm a maintenance programmer, for the purposes of this project, and it is a complete nightmare. Apart from the fact it uses two different J2EE frameworks (yes, really) and over 50 different external JAR files, the thing is an XML configuration file nightmare. All the tools that my IDE provides are useless as so much of the application structure is in XML files.

Kawazu: I agree that some things are OK in configuration files - paths, URLs and so forth. The problem is that the most significant parts of the application logic are in various XML files. As I already said, this renders most of the tools I have for grokking the application useless. I don't believe that Spring+AOP+XML does keep the code "clean", all it does is hide the messy bits in XML files - it's still a mess, but it is now a mess that is split over two different technologies, Java and XML, and two technologies that have a huge "impedance mismatch". I'd actually prefer to have all the configuration done in POJC (Plain Old Java Code), because that's what the XML goop actually ends up as anyway, and at least if it is Java I can use debuggers and code inspectors on it. I just don't understand what benefits XML is supposed to have - I can't think of anything that can be done in XML that couldn't be done in Java.

Re: XML-based J2EE frameworks considered harmful

XML is assumed to be a language because its name says so! In order to avoid this confusion, I think XML should be called as XMD (eXtensible Markup Document). But it might be too late in the game to change the name. Just like the name 'SOAP' has nothing to do with Objects, we have to live with the 'XML' name.

Re: XML-based J2EE frameworks considered harmful

XML is wonderful for storing databases, and other sorts tree-style data storage, but I fully agree that it's not, nor should it even be looked at as if it were, a programming language. It exists for markup.

Daisychain: are you suggesting that HTML is also assumed to be a programming language? Titles are meant to be read as a whole.