Gregory V. Wilson: "It's the XML Configuration File's Fault"

Discussions

Blogs: Gregory V. Wilson: "It's the XML Configuration File's Fault"

  1. Gregory V. Wilson, an editor for DDJ, has an interesting article on DDJ called "It's the XML Configuration File's Fault," explaining why he switched from Java and switched to Python.
    It's been almost a year since I wrote any Java, and I have finally figured out the real reason I gave up on it and switched to Python. It's nothing to do with the language itself--I often miss the sanity checks that come with strong typing. And it certainly wasn't because Java lacked tools, libraries, documentation, or an active developer community.

    No, the reason I switched can be summed in a single phrase, one that I've come to dread--XML configuration files. You have to write one for Ant to describe what you want to compile, a second for Hibernate to tell it how to map your classes to the tables in your database, a third for Tomcat to tell it how to map URLs and HTTP requests to your app, and on and on and on.

    Threaded Messages (14)

  2. Amen[ Go to top ]

    Twenty-four years after I wrote my first Makefile, I still can't set a breakpoint in one to find out why a particular intermediate file is being regenerated more often than I think it should be. There are hundreds of very cool plugins for Eclipse, but none that can point and say, "There--that line there is why this HTTP request was mapped to that servlet," or, "Hibernate is doing this query to get your object because of the bits of XML here, here, and here." Until such tools come along for sturdy languages like Java, C++, and C#, I'll stick to agile languages that let me debug as efficiently as I code.
    Gregory hit in on the nail.
  3. Amen[ Go to top ]

    iBatis has done that to some extent. It points out faulty statements and parameter definitions.

    But everything else...well, if you abuse the technology, it will bite you in the ass, so do not complain and make sure your application is architected such that it does no have million differently formatted XML configuraiton files.
  4. Good plan, but how?[ Go to top ]

    In my small project:

    0) server.xml, Tomcat config
    1) build.xml, self-explanatory
    2) web.xml, self-explanatory
    3) xxx-servlet.xml, Spring config
    4) xxxx.xsd, to parse other XML files
    5) xxx-dwr.xml, for DWR Ajax support

    I don't even have a persistence layer, it's not required for this project, but of course most do and would require another XML file to configure that. Imagine if I was using JSF.

    The author is right, we're letting configuration files take over the development process. At least Spring is very good at pointing out problems in its configuration, other projects should take note of how well it handles this and follow suit.
  5. Actually, from my point of view, that situation of many XMLs that map and configure things to direct the software Engine to do the work for you.

    this has nothing to do with some programming language, it is a strategey and design of a system, simply wait more 3 years and you will find the same java tools for python that uses XML :D
  6. I haven't used it, but from what I've read, Ruby on Rails works by simply having 'intelligent' defaults for things. So you name things in a certain way and you don't need to configure it, since you've already set it up. It'd be like always laying your project out in exploded webapp format and therefore not needing to package or deploy it other than copying it.

    Obviously that has downsides if you can't change the defaults, but more of that and less of having to specify _so_ much would be nice. Of course, annotations *might* help here, although they might hurt too... I'm not sure how I feel about having annotations all over the place, but they definitely can reduce the amount of trivial config you have to do.

    For instance, in DWR, you could at least have an annotation to mark a method available for JavaScript calls to it. In fact they could probably piggy back on similar annotations which exist for other RPC purposes.

    --james
  7. this has nothing to do with some programming language, it is a strategey and design of a system, simply wait more 3 years and you will find the same java tools for python that uses XML :D

    True, it's a design decision to make things configurable (ie, easy to change without re-plumbing the entire system), but his point is that "configurable" doesn't have to mean "in XML". As he says, Java doesn't "let you write out data structures more complex than arrays directly"...in Ruby/Perl/Python, you "use the programming language itself for expressing configuration."

    Imagine if configuring your web app was done by implementing some interface, instead of a creating a web.xml. You'd have to code up this other class, which would be a pain (it'd have a Collection of servlet mappings, of servlets, of filters...), but you could see the configuration right in front of you. You could debug your way through it. This is what he's talking about -- the diff. is that in Python, it's not a pain to create these "config objects", because it has better support for native, complex data structures. Which is why you won't "find the same java tools for python that uses XML" in 3 years.
  8. Inheritance for Annotations?[ Go to top ]

    I couldn't agree more with what everyone is saying. I don't mind Spring configuration files so much, I find they actually help me focus on what I cobbling together as an application.

    My biggest dilemma is when using Hibernate. I really don't feel like hand writing all the mapping files by hand so I have turned to annotations. They are great! Since they are compiled I know if I misspelled something, using an incorrect class, etc. And my IDE has the autocomplete (whatever you call it) so it takes me much less time to write the same specification.

    But lately I am finding that I want to reuse some of my classes in different projects. Fairly complex classes at that. But I don't necessarily want to use the same mapping strategy because either I need different table and column names, different lazy fetching strategy, or I don't need one of the entities it is mapped to (and Hibernate won't work unless you have configuration files for the entire hierarchy of related entities).

    To work around this I started writing wrapper/proxy classes that just pass through all the calls and place my desired annotations in that class. But it feels like such a huge waste of time, I am writing hundreds of lines of code that do nothing just so I can override annotations. I guess this is where everyone here would say I need a tool to automatically generate all my wrappers?!?

    I am now thinking of going back to the original XML mappings because I can use the same class but can use different configurations for different projects. I am really dreading this...

    I don't have a great idea of what the right solution is, but I am in love with the new annotations and have a gut feeling like there is some potential there...

    Any thoughts?
  9. XML files are equally unreadable by people and computers.
  10. I'd like to know how you can just decide to change from Java to Python? The market ususally decides for the great majority of professional developers. I'm a full-time Java monkey and have been for several years and Java doesn't even come in my top 5. But I can't just decide to switch and still put food on the table.
  11. Putting food on the table[ Go to top ]

    I'd like to know how you can just decide to change from Java to Python? The market ususally decides for the great majority of professional developers. I'm a full-time Java monkey and have been for several years and Java doesn't even come in my top 5. But I can't just decide to switch and still put food on the table.

    No kidding. I've been teaching myself Ruby for a few months now, trying to squeeze it in on the side, because I feel strongly that learning a dynamically-typed language is a Good Thing to do...it's already made me look at Java differently in a few ways. But using it at work? Finding a Ruby job? Not much luck yet...
  12. ... and I thought I was the only one who felt that config files are "dreadful"!
  13. In the ObjectGrid (WebSphere XD), I took the approach of using POJO's for all config APIs. Now, a customer can choose to use our XML config module or an IoC container like Spring to bootstrap the ObjectGrid and configure it but thats their choice. They can just as easier configure it with APIs for more complex scenarios but we use reasonable defaults for all the bits so for a simple 'make a local cache' application, it takes a few lines of Java with no XML.

    Billy (IBM)
    http://www.billynewport.com
  14. Whiny[ Go to top ]

    What a bunch of whiny whiners!

    When a programmer is faced with a boring repetitive task, what do they do?

    They AUTOMATE it!

    Damm, I'm glad I never worked with you guys, imagine the doom and gloom.

    And, on another note, maybe its time for a Config service that just doles out java config objects registered against a name ( maybe JNDI ). ConfigLoaders can populate these from many data stores, including the command line, XML files, property files, DBMS's, serialized objects, YAML, jython/jruby etc.

    One of the cooler hacks I saw for using XML config in your own app was to register an XSLT extension function which called Config object methods to populate a Configuration. Nice, no boilerplate code, very flexible.
  15. Whiny[ Go to top ]

    What a bunch of whiny whiners!When a programmer is faced with a boring repetitive task, what do they do?They AUTOMATE it!Damm, I'm glad I never worked with you guys, imagine the doom and gloom.

    Imagine the doom and gloom? Imagine this... imagine that without people being dissatisfied with the way things are that we wouldn't even have a Java... or a C++, or a C, or a microwave, or a flip-down TV in the car. The point is that being dissatisfied with the way things are drives innovation.

    In the second half of your email you even came up with a possible solution to a dissatisfied programmer. Isn't it amazing how these whiners got the creative juices fowing?

    Way to go you doom-and-gloomer's! Just remember - it's the squeaky wheel that gets the grease.

    AUTOMATE, yes, but more importantly INNOVATE!