according to Twitter subscribe to my twitter feed

    Java application config choices

    I took some good-natured jibing on my last project about the level to which I wanted to make the application configurable. My innate pedantry meant that I was driven to throw as much of the configuration and even logic into external files. Frameworks like Spring positively encourage this - why would you ever have a hard-coded static constant, when you can inject a value from xml? And why stop there - why not config your Spring config files with a PropertyPlaceholderConfigurer... Well, my colleagues have made me think a bit more about this approach. Clearly, there is some config data that no-one is quibbling about - database credentials for exmple, simply do not live hard coded into the application. But what about other meta data? Like say a number format pattern? Or an SQL string?

    There are lots of choices for where metadata can reside, and picking the appropriate one is key. Databases and properties files are great for config that often needs changing on the fly. For example, the number format for a column in an online report. However, they add a level of indirection during development which is anooying as the data is physically separated from the source. They are also not well suited to refactoring, although IDEs ease some of the pain these days.

    Annotations are at the other extreme as they are bound to the source. They're appropriate for a different category of metadata - when your config drives the code's core functionality. The classic example is a SQL (or an object query language) string which is well suited to living in annotated methods in DAOs. There is no point having it in an easliy-changed properties file because when you change your SQL you are fundamentally impacting the behaviour. That is not a runtime activity. However, annotations are more verbose to create. Moreover they are easily abused and overused resulting in bloated, messy code.

    As an aside, and a great example of annotation abuse, I really don't like JUnit 4's @Ignore - if the test is broken then fix the damn thing! That is just encouraging sloppiness. It is even worse than commenting out a broken test as it kind of looks official - like you somehow meant to do it. As much as I hate to admit it, at least a chunk of commented out test code is a big red flag that shouts at you to go back and get the thing to pass.

    So to sum up, the choices available in Java are increasing all the time. Spring for example ships with more and more annotations. In addition support is there for bean wiring by xml, properties files and programatically through the api. In a slightly obtuse way, their new dynamic language support can be thought of as config - you can certainly use it to inject new bahaviour at runtime. The choice can only be a good thing (I don't want to be forced to use EJB 2 deployment descriptors ever again). It just means I've got to think more carefully about where application metadata should live and not just dump anything that looks like config into properties files.

    Labels: , ,