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?

Nav
  • 1,173
  • 1
  • 11
  • 23
  • 3
    Possible duplicate of [When to use Constants vs. Config Files to maintain Configuration](http://softwareengineering.stackexchange.com/questions/121221/when-to-use-constants-vs-config-files-to-maintain-configuration) – gnat Mar 07 '17 at 09:58
  • Thanks @gnat, but my question is specific to the Java `application.properties` file, and it isn't about constants vs config. – Nav Mar 07 '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](http://softwareengineering.stackexchange.com/questions/342087/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 07 '17 at 10:16
  • 1
    You should listen to your boss: he is correct. –  Mar 07 '17 at 23:26
  • 1
    Somewhat incidental to your question, but since Java 1.4 (2002), the [`Preferences API`](https://docs.oracle.com/javase/8/docs/technotes/guides/preferences/overview.html) is preferred over plain `Properties` for this sort of thing. – Kevin Krumwiede Mar 08 '17 at 20:33
  • Hey, this is nice. I didn't know Preferences API was created as a replacement for `application.properties`. Thanks for sharing. – Nav Mar 11 '17 at 14:50
  • About the comment/uncomment thing, look into profiles - that way you can have DEV and PROD profiles with two different `application.properties` files. – cst1992 Sep 24 '17 at 10:58

1 Answers1

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.

J. Lenthe
  • 365
  • 1
  • 5