Alan Burlison's Work Related Ramblings

Tuesday May 29, 2007

Someone had to do it

/dev/bollocks goes Web 2.0

The birth of a new programming language

A rare chance to watch (and even contribute to!) the birth of a new programming language - lolcode.com. 1337!

Thursday May 03, 2007

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