Many articles talking about how YAML file configuration is more advantageous over properties file, offering enhanced capabilities and more clarity. At a glance, the claim certainly seems true. It’s almost a no-brainer, after reading such articles, to conclude that YAML file is the superior version, the most effective, the “meta” of Spring Boot’s configuration file, if I must say.

Unfortunately, very few argue when and why using properties file is sometimes better. If you are working on multiple-related projects, or have access to tens or hundreds of projects, repositories, then here are more reasons to why using properties file may be more favorable and practical than using YAML file.

1. Maintain consistency with legacy code

This is often the only argument I found for when properties file is preferred. A valid argument, but the same should be true for YAML file.

It’s recommended to stick with one format in your project. If you have both properties and YAML files in the same location, properties file takes precedence. If your workplace has so many projects that are already using properties file, then using properties file, even for new projects, may give you another advantage that YAML can’t offer, see points below.

2. Matching the format of Spring Boot’s documentation

The real advantage is, in my opinion, it’s easy to look up the documentation in Spring Boot code. Just search a property key from properties file to find the documentation. Want to use some properties? Just copy-paste the properties from the documentation and set the value. Try to do that on YAML property without using dot notation, without extra steps, without extra tools.

To get a clearer idea, see:

• https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html
• (sign in needed) https://github.com/search?q=repo%3Aspring-projects%2Fspring-boot+spring.threads.virtual.enabled&type=code

3. Easier to read and find

Because each property is a put on separate line, it’s easier & faster to read the full key. With YAML file, the property could be (nested) deep enough, making it hard to read the full property key with just a glance.

Flat properties are also easier to search. We could use wildcard or regex. “@Value” is also using the same dot notation as properties file, so all of the references will also be correctly returned.

Suppose we want to find other repos that are using HikariCP properties (for research or references), just search “spring.datasource.hikari".  Find all API clients' properties of a specific backend url? Just search “exampleClient.url=http://example.com”, for example. Or during debugging, when we need to find out the value of some properties that are used by the application. 

See for example (sign in needed):
https://github.com/search?q=spring.kafka.producer.acks&type=code

With YAML, it will be hard to find the exact properties without extra steps or tools. Of course we could use flattened properties with dot notation in the YAML file, but that would defeat the purpose of using YAML to reduce repetitions.

spring.datasource.hikari.maximum-pool-size: 10
spring.datasource.hikari.minimum-idle: 3
spring.datasource.hikari.idle-timeout: 300000

Some IDEs offer capability to find a property in YAML file using the dot notation, but it only works locally. If we want to search over tens or hundreds of repos, it’s easier and faster to search on the VCS hosting’s web interface. Still, at the time of writing, all of top 3 Git hosting services (GitHub, GitLab, Bitbucket) can’t seem to find a property in multi-level, indented YAML files using the full path dot notation.

4. @PropertySource doesn’t accept YAML file by default

It’s mentioned in the Spring Boot doc, and it is kind of surprising because it violates the principle of least surprise. There was a request to add the support, but it had been rejected by the Spring Framework team. There are workarounds to add the support, but still not free.

Conclusion

Even though this is an argument for using properties file, for side or pet projects, I prefer using YAML file. It reduces repetition and gives more clarity to the data type.
For working with large number of projects with large codebase, however, using properties file is definitely well worth considering.