"Unknown property" marker is created when there is a setter but no getter

[eric-creekside]

STS for Eclipse Version: 4.21.0.RELEASE

In application config YAML files, STS will mark a property as unknown (error or warning depending on how I have STS configured) even if there is a setter for that property in the corresponding Java @ConfigurationProperties class. If I have both getter and setter, the error/warning goes away.

For example, given this class:

@ConfigurationProperties(prefix = "foo")
public class MyProperties {
	private String envName;
	public void setEnvName(String name) { };
}

and this YAML:

foo:
  envName: bar

STS puts an error/warning marker in the YAML saying envName is an unknown property.

If I add this getter to MyProperties:

	public String getEnvName() { return ""; }

Then the YAML error/warning goes away.

It seems that a property with only a setter shouldn't trigger an error/warning, since all that matters to Spring is that it can know where to put the value from the YAML.
Before anyone starts quoting the Java Beans spec to me, I know that a property with no getter is not a strict Java Beans property. Practically speaking, however, Spring doesn't care; it still correctly sets the YAML value into the config object. So STS is not agreeing with Spring's own runtime behavior.

[BoykoAlex]

@eric-creekside I have looked at the <output folder>/classes/META-INF/spring-configuration-metadata.json file (target is the <output folder> for maven - this is the file generated by spring boot via the spring-boot-configuration-processor. This is the metadata that IDE uses to provide assistance with Boot properties. This file is generated by the Spring Boot.

If getter or setter is missing for the property then the JSON file misses the metadata for the property. This is because both the setter and the getter are required to be present for a property. Thus, it is kind of enforced this way via properties metadata. I quickly asked Boot team and the reasoning is if everything that looks like a setter would be accepted without having a getter then too many properties would be exposed.

Anyway, STS works as designed with respect to Boot properties. The Spring Boot requires both getter and setter.
(Also see docs: https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.typesafe-configuration-properties.java-bean-binding)

[eric-creekside]

@BoykoAlex Like I said, I know what the documents and Java Beans say, but Spring's own behavior does not agree. I have several @ConfigurationProperties classes with properties that have no direct getters, and the values do get populated from my YAML config files. A simple example app can prove this; if I construct a simple project to demonstrate it, will you consider re-opening this issue?
I'm on Spring Boot 2.5.x, if that mattes.

[BoykoAlex]

@eric-creekside The metadata file <output folder>/classes/META-INF/spring-configuration-metadata.json is generated by Spring Boot - we have no control over the contents of this file. However, we use the content of the file for the tooling to report errors and provide completion proposals. Folks from Spring Boot team told me that getter and setter are both required by design and hence metadata generation won't be changed.
I'd bring this up to Spring Boot team as an issue perhaps (via https://github.com/spring-projects/spring-boot). We cannot change this behaviour on the tooling side unless we generate the metadata ourselves which we don't plan on doing.