Java programmers are encouraged to store all their configurable parameters in an
application.properties file from which they either load properties during runtime or they load during program start and assign them to variables in a config file.
The way I used it was to store variable values that I need to tweak between program runs. I also used to store database connection strings and database domain names in
application.properties, but recently moved these into the code because it was a pain to comment out multiple lines when choosing to shift between running on local and on production server.
sql.connString=someProductionString #sql.connString=someLocalhostString sql.domain=productionDB #sql.domain=localhost mongo.connString=someProductionString #mongo.connString=someLocalhostString mongo.domain=productionDB #mongo.domain=localhost
It was easier to have the above lines within the code and to change just one line
My boss however, says that:
1. The database connection strings should be in
application.properties itself, as another developer collaborating on my code would find it easy to know what those strings are.
2. He also says that if I have variables that I need to tweak between program runs, they should be placed in the code, inside the object that uses those variables.
3. When the tester or the QA person uses my project, they would substitute my
application.properties file with an
application.properties file of their own which would be relevant to the environment they are running the program in.
He explicitly said that I have to prioritize these conventions above my convenience and that only generic variables are to be stored in
application.properties; all other variables are to be stored local to the object that uses them. Apparently, there are many open source projects which use the properties file in a certain way.
I don't buy it because all the above reasons waste time. Why spend time commenting and uncommenting lines and/or changing variables in code and recompiling?
Is there a recommended way to use