See https://github.com/spring-projects/spring-boot/issues/34195

Comment From: snicoll

Ironically enough, that broke the use case in the linked issue as anything that implements CharSequence now is going to be handled as a String down the road and the proper conversion won't happen as expected.

Reverting.

Comment From: snicoll

This was reverted in 94348d9d41764900a

Comment From: quaff

Ironically enough, that broke the use case in the linked issue as anything that implements CharSequence now is going to be handled as a String down the road and the proper conversion won't happen as expected.

Reverting.

Could you elaborate what is broken? CharSequence is an interface, returned String object implementing that interface seems correct.

Comment From: snicoll

You could try your change against the change you've made in Spring Boot and you'll see by yourself.

Comment From: quaff

You could try your change against the change you've made in Spring Boot and you'll see by yourself.

        MockPropertySource propertySource = new MockPropertySource();
        propertySource.withProperty("v1", "1");
        propertySource.withProperty("v2", new CharSequence() {

            static final String underlying = "${v1}";

            @Override
            public int length() {
                return underlying.length();
            }

            @Override
            public char charAt(int index) {
                return underlying.charAt(index);
            }

            @Override
            public CharSequence subSequence(int start, int end) {
                return underlying.subSequence(start, end);
            }

            @Override
            public String toString() {
                return underlying;
            }
        });
        environment.getPropertySources().addFirst(propertySource);
        assertThat(environment.getProperty("v2")).isEqualTo("1");
        assertThat(environment.getProperty("v2", Integer.class)).isOne();

The v2 is equal to ${v1} before. after this changes, it's expected 1, and I tried value from ConfigTreePropertySource is resolved too, what's the problem here?

Comment From: snicoll

You're missing the point, it's the other way around. org.springframework.boot.env.ConfigTreePropertySource.Value implements CharSequence and now goes through the instance of check that this PR changed rather than being handled as a Value.

Comment From: quaff

You're missing the point, it's the other way around. org.springframework.boot.env.ConfigTreePropertySource.Value implements CharSequence and now goes through the instance of check that this PR changed rather than being handled as a Value.

I'm aware of that, I don't think application would rely on type Value since it's kind of internal type.

Comment From: quaff

You're missing the point, it's the other way around. org.springframework.boot.env.ConfigTreePropertySource.Value implements CharSequence and now goes through the instance of check that this PR changed rather than being handled as a Value.

@snicoll Please see https://github.com/spring-projects/spring-boot/pull/40862#issuecomment-2141158421, I will submit another PR if that fix is acceptable.

Comment From: snicoll

chatting with @wilkinsona, we can reconsider this by looking for the target type as well.