I had to add some features in a report. The report is configured in a context class written in Java. Fields and other configurations are hard coded as variables. It was the opportunity to update the code to avoid refactoring each time something new was needed. I created a property file and a parser. Now it was all good to go… BUT! mistake on my behalf. This application was not a web application, but a heavy client written with Netbeans Platform. I jumped into this property file by force of habit. A property file does not fit a heavy client well. Why?
# CONFIGURATION for ReportX # field definition configuration my.report.field.property1=123 my.report.field.property2=345 my.report.field.property3=456 # calculation configuration my.report.calculation.configuration1=property1+property2-property3 my.report.calculation.configuration2=property1-property2-property3 my.report.calculation.configuration3=property1*property3
- No code to change.
- Configuration easy to change without compiling, packaging, deploying and restarting the application.
- Compact appearance.
- Configuration mistakes not easy to detect. Typo or missing configuration are detected by IDE in the case of global constants.
- Parser code more complex than listing constants.
- Configuration format needs to be defined somewhere.
- In the case of a heavy client, users can potentially update the file even if it is included in a jar file.
- In the case of a heavy client, changing the property file still implies deploying it on all the machines => which voids the greatest benefit of having a property file.
In conclusion: context matters. Unfortunately, one size does not fit all – especially when it comes to programming. In this case, a property file is not helpful and more prone to errors than constants.