Java and XML configuration

It is standard practice in programming to avoid “magic numbers” — not just numbers, but any kind of fixed constant that you might have to change in the future. It's sometimes useful to remove these constants from program code entirely, shuffling them into a configuration file that is loaded by the program. This means you can adjust configuration without rebuilding the program.

In Java, this has progressed to the point where almost every aspect of a “good” program is specified in XML configuration files (probably with liberal use of FactoryFactoryFactories). The justification for this is the immutability of the code itself: in scripting languages, it is more common to modify a piece of program code to adjust configuration, but Java is too brittle. (This does not necessarily mean that you edit the actual program: instead, the configuration can be written in the same language as the program.)

Now let's look at the situation with deployed servlets. Each servlet has a deployment descriptor (e.g., sip.xml), which allows you to embed configuration elements, analogous to shell environment variables.

You have your code and deployment descriptor open in Eclipse. When you deploy the servlet, the compiled code is packaged up with the XML into a sar or war. That archive is put on the server, which loads it into the running application to start handling requests.

Eclipse compiles behind the scenes; you never have to hit ‘Build’, or wait for a compile to finish. Modifying the code is actually quicker than modifying the configuration file, because its support for XML or the deployment descriptor format compares infavorably to that of code. You can't deploy the descriptor separately from the class files, and you cannot reliably edit it once deployed. Why, then, should I spend more effort putting configuration into the XML environment? If I need to change something, it's quicker to change the code and redeploy than it is to change the XML and redeploy, and there's less to go wrong.

By keeping some constants in code, rather than expending effort to make every aspect of the application configurable, I avoid YAGNI. I can see real values while I'm making logic changes. I can exploit the IDE and the type system. I avoid the possibility of vital configuration information escaping from version control, where the code lives.

Java needs an overhaul… or, rather, the way people use Java needs an overhaul.

Posted at 2007-08-24 14:14:16 by Richard • Link to Java and XML confi…
Comments, trackbacks.