SpringBoot Spring Boot configuration doesn't fail on unresolved placeholders

Application doesn't fail if missed placeholder is used in the configuration properties and leaves the value with the dollar sign. The problem exists only only for classes with @ConfigurationProperties

It should work the same way as @Value does and fails with IllegalArgumentException: Could not resolve placeholder 'missing-placeholder' in value "${missing-placeholder}".

I checked that simply applying the @Validated and @Valid annotations to the class and field do not help. I also found the question https://stackoverflow.com/questions/43493346/unresolved-placeholder-validation-for-spring-boot-configuration-properties but without any meaningful answers.

Below is the example:

application.properties my_prop=${missing-placeholder}

DemoApplication.java

@SpringBootApplication
@EnableConfigurationProperties({MyConfig.class})
public class DemoApplication {

    @Autowired
    private MyConfig myConfig;

    @PostConstruct
    public void setUp() {
        System.out.println("Config value: " + myConfig.getMyProp());
    }

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

MyConfig.java

@ConfigurationProperties()
public class MyConfig {
    private String myProp;

    String getMyProp() {
        return myProp;
    }

    void setMyProp(String myProp) {
        this.myProp = myProp;
    }
}

OUTPUT Config value: ${missing-placeholder}

Comment From: wilkinsona

Duplicate of #4302

Comment From: wilkinsona

The difference in behaviour to @Value is intentional. If you want the same behaviour as @Value then you should use @Value.

Comment From: splevko

What is the reason not to fail in the case like this?

spring:
  datasource:
    url: jdbc:postgresql://${POSTGRES_HOST}:5432/document-converter

Comment From: wombat9000

Just encountered this behaviour today, and also interested to understand the reasoning.

Comment From: wilkinsona

There's some discussion in #4302. I can't speak for @dsyer, but not failing is considerably more flexible. It allows a consumer of a property to make a decision about what to do with the unresolved placeholder which you don't get with @Value. Dave may have additional or different reasons for considering the behaviour of @ConfigurationProperties to be better.