6

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 domain.isRunningOnLocal=true in application.properties.

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 application.properties?

7
  • 3
    Possible duplicate of When to use Constants vs. Config Files to maintain Configuration
    – gnat
    Mar 7 '17 at 9:58
  • Thanks @gnat, but my question is specific to the Java application.properties file, and it isn't about constants vs config.
    – Nav
    Mar 7 '17 at 10:07
  • if you need a closer match to what you ask about in comments, it would be Deciding what values should be configurable. However I believe that the question referred before is better in addressing your concerns in the question. With regards to your boss requiring to limit content of application.properties file, this is a really minor issue that is easy to solve by introducing a second config file to store any values you like
    – gnat
    Mar 7 '17 at 10:16
  • 1
    You should listen to your boss: he is correct.
    – user22815
    Mar 7 '17 at 23:26
  • 1
    Somewhat incidental to your question, but since Java 1.4 (2002), the Preferences API is preferred over plain Properties for this sort of thing. Mar 8 '17 at 20:33
6

In a well-designed server application, environment-specific configuration data should be externalized from the app itself (i.e jar or war file) so you don't need to rebuild the app for every environment it has to run in. Typically a serious application needs to run in a variety of environments (local, test, demo, production, various client deployments, geographically redundant backup site, etc.). So if there's an application.properties file in the app itself, it should contain only default values and there should be way to override those values in the environment.

In a Spring Boot application, for example, there are several places it can read an application.properties file from such as the current working directory and it will use it to override values from an application.properties file on the classpath. It also supports the concept of profiles, so you can select from different versions of an application.properties files within the app via a command line argument (and still override them with an external application.properties).

The bottom line is: you should ask your boss the best way to override values in your app's application.properties files without rebuilding so you can properly get set up to run locally. If he says that there is no way, I would ask to get one implemented. It's crazy to have to keep a modified file from the code repository around perpetually just to run locally.

As an aside, and of course it depends on the specific architecture but, I think it is usually a bad idea to store real production credentials in the code baseline because if someone gets a copy of the code they may now have access to production data and the ability to delete it all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.