Alan's Ramblings - xml tag

XML-based J2EE frameworks considered harmful

Thu, 03 May 2007 03:44:05 GMT

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?"

Why I hate XML configuration files

Thu, 05 Apr 2007 14:38:44 GMT

I'm working on a reasonably large (1000+ source files) J2EE application that makes extensive (some might say utterly excessive) use of external components - it requires in the order of 50 JAR libraries to run, over and above the standard J2EE ones.

And of course many of those JAR files have their own unique XML files to configure them.

And of course many bits information related to the configuration of the application (URLs, database details etc) have to be repeated in more than one of those XML files.

And there's no global way of doing this.

So the people who originally wrote the application came up with a scheme - they'd store the configuration values in property files.

But that only helped for things that got the values dynamically, for example by using the J2SE Properties class. All those external components they'd used didn't know anything about the application's property files, they only knew about their own unique little XML files.

So the people writing the application came up with another scheme - they'd embed tokens in all those little XML files, then use the Ant Filter task to replace them at build-time with the values from the property files.

"Job's a good 'un!" they doubtless exclaimed, flushed with their extreme cleverness.

Then I came along and had to maintain the beast, when I found:

There are in excess of 50 of these properties, which makes configuring the application more than a little tedious and more than a little error-prone.
The names of the tokens processed by the Ant Filter task and the names of the properties used to set their values mostly bear very little relationship to each other.
There is no consistently-applied property naming scheme. There are in fact several inconsistently-applied naming schemes.
Some of the properties are just renamed versions of other properties. Sometimes they are inconsistently renamed versions of other properties. Sometimes they don't appear to be used at all.
It isn't clear when reading a property file which properties are only used at compile time by the Ant Filter task, and which properties are only used at run time. It's also unclear which ones are used at both compile and run time.
The compile-time use of properties is a killer because it means the application can't realistically be reconfigured without recompiling it - because the use of the Ant Filter task means the compile-time property file values end up hard-coded in many different places. It's therefore pretty much impossible to produce a version of the application that can be deployed on more than one machine - for example for development or test purposes.

All this means that there's a whole series of bear traps set for anyone who innocently changes any of the properties files of the application, in the mistaken assumption that the application will actually take any notice of them.

I'm sure I'm not the only person to have been hit by this problem - how to configure multiple external components which all have their own XML configuration files - without having to hand-edit each of the XML files each time every time something changes, and without hard-coding the configuration at build time. However I'm damned if I know of a good way of doing it - although I can easily think up several not-very-good ways of doing it.

If you know, please let me know!

Why I hate XML, and Ant's use of it in particular

Sat, 25 Mar 2006 08:26:49 GMT

I was googling around for examples of how to sign a JAR file in Ant using the signjar task and came across this monstrosity - 217 lines of turgid XML. How anyone can say Ant is an improvement over make is a mystery to me, and how anyone could ever think that XML is fit for consumption by humans is an even bigger mystery. XML is food for machines, not people. I sincerely hope that the current fad for doing everything in XML (and we have some examples close to home) is going to an early grave.

What I'm actually trying to do is to deploy an application via WebStart from within NetBeans - I've loaded up the NetBeans WebStart module but it really doesn't cut the mustard yet, it doesn't support JAR signing, it hard-codes the name of the JNLP file and it assumes you want a WAR file building. Here's hoping they make the necessary improvements in short order.