One of the methods of loading properties files as described by the documentation is:

  1. Application properties outside of your packaged jar (application.properties and YAML variants).

This appears to mean that the application.properties file should be placed in the same directory as the jar file. What I have found though, is that it will pick up the properties file that is in the current working directory, irregardless of the location of the jar file. For example, if I have the following files.

build/libs/application.properties build/libs/application.jar

If I execute the jar from the build directory using java -jar libs/application.jar, it will not pick up the properties file. If I change the working directory to build/libs and execute java -jar application.jar, it will pick up the properties file.

I would think the more sensible and stable behavior would be to figure out the directory of the jar and use that. If that is not possible, or not what the intended behavior is, then the documentation should be updated to clarify.

Comment From: spencergibb

Slightly further down the docs explain where, by default, they are loaded from and how to change it.

https://docs.spring.io/spring-boot/docs/2.3.1.RELEASE/reference/html/spring-boot-features.html#boot-features-external-config-application-property-files

Comment From: wilkinsona

The outside in "Application properties outside of your packaged jar" means files that are not inside the jar. It isn't intended to say anything about the locations outside the jar from which they are loaded. This is much the same as the next bullet that doesn't precisely define what inside means. The locations, both inside and outside the jar, are defined more precisely in section 2.3:

  1. A /config subdirectory of the current directory
  2. The current directory
  3. A classpath /config package
  4. The classpath root

Here, 1 and 2 are outside of the jar (or, more accurately, outside of the classpath as the same applies when running an exploded jar or in your IDE), and 3 and 4 are inside the jar (or, more accurately, on the classpath).

It sounds like we should clarify things to make it a bit clearer what outside the jar means. Linking to section 2.3 from bullets 14 and 15 may be the best option.