IDE configuration metadata does not respect `@Name` annotation for property binding

[libedi]

Summary

When using Spring Boot configuration properties that rely on the @Name annotation, the IDE (STS) appears to generate or interpret configuration metadata based solely on naming conventions, ignoring the explicit name defined by @Name.

This leads to incorrect property suggestions and misleading configuration guidance in the IDE.

---

Environment

• Spring Tools for Eclipse 5.0.0.RELEASE
• Spring Boot version: 4.0.1

---

Problem Description

In Spring Boot 4.0.1, the following configuration properties class exists:

org.springframework.boot.http.client.autoconfigure.ApiversionProperties

The relevant field is defined as:

@Name("default")
private String defaultVersion;

At runtime, the correct property name that binds successfully is:

spring.http.serviceclient.{group}.apiversion.default

However, the IDE configuration metadata / auto-completion suggests:

spring.http.serviceclient.{group}.apiversion.default-version

This suggests that the IDE is deriving the property name from the field name (defaultVersion) instead of honoring the explicit @Name("default") annotation.

Actual Behavior

• IDE auto-completion and metadata suggest default-version
• Using default-version has no effect at runtime
• No warning or error is shown in the IDE

Expected Behavior

The IDE should:

• Respect the @Name annotation when generating or interpreting configuration metadata
• Suggest the effective property name:

  spring.http.serviceclient.{group}.apiversion.default

• Avoid suggesting properties that do not bind at runtime

Impact

• Developers are guided to configure incorrect properties
• Results in silent misconfiguration without IDE feedback
• Requires source-level inspection to identify the issue

Notes

This issue may be related to how the IDE processes Spring Boot configuration metadata and custom property naming annotations such as @Name.

Improving support for @Name would significantly reduce confusion and misconfiguration in IDE-assisted Spring Boot development.

[martinlippert]

Related issue: spring-projects/spring-boot#48611

[snicoll]

I've closed the duplicate. This arrangement is a bit unusual and I don't think we had that case before.

In short, when you discover a POJO that's the target of a map or a list, the same rules should apply to the pojo. With a regular object, you don't have to worry about those as the metadata is correctly generated for you. However, this isn't the case at the moment for maps.

I suppose that if you link a property to where it's defined, you'd have to handle @Name in any case. Let me know if I can help.

[libedi]

@snicoll
Thanks for the clarification, that makes sense.

I’ve attached a screenshot to better illustrate the current behavior.
In the IDE, the default property (which is the one that actually binds at runtime) is marked as invalid, while default-version shows no error.
However, in practice, only default works correctly and default-version is ignored.

This made me wonder about the original intention behind using @Name("default") here.
Was there a specific reason why the property couldn’t simply be exposed as default-version?
Or is there another recommended way to avoid this mismatch between runtime binding and IDE metadata/validation?

I just wanted to better understand the design choice and whether there is an alternative approach to address this from a user perspective.