Affects: 6.1.5

I have a third party library that compiled without -parameters flag, but I know it has more or less standart annotation @ConstructorProperties on the constructor. I can find that BeanUtils.getParameterNames relies on the annotation mentioned. What do you think about the idea to move 

ConstructorProperties cp = ctor.getAnnotation(ConstructorProperties.class);
String[] paramNames = (cp != null ? cp.value() : parameterNameDiscoverer.getParameterNames(ctor));

from BeanUtils.getParameterNames to StandardReflectionParameterNameDiscoverer (maybe naming could be corrected)?

Comment From: snicoll

@g-sg-v thanks for the suggestion but we'd be more interested to understand the use case. As you are probably aware, we do support ConstructorProperties for data class binding as well as constructor-based bean instantiation through direct checks and we'd like to understand why you need this for ParameterNameDiscoverer.

This infrastructure is not meant to detect JavaBeans annotations so we can't really add that there. But perhaps we can improve something based on a complete description of your use case.

Comment From: g-sg-v

Hi Stéphane, thank you for response. I'll try to provide the example. Probably you can advise me how to solve my problem without code changes =)

I have 3 third party library that compiled without -parameters flag and I would like to use a class from the library to describe propeties requiered by the lib (in my case class YdbConfig):

@ConfigurationProperties(prefix = "ydb")
public record YdbProperties(
        YdbConfig config
) {
    public YdbConfig config() {
        return config;
    }
}

and I have a section in my application.yaml:

ydb:
  config:
    database: /local
    tablespace: /local

When I'm trying to run my application config field is null, message from ValueObjectBinder appears. I didn't found any ability to change discoverer:

private static final ParameterNameDiscoverer DEFAULT_DELEGATE = new DefaultParameterNameDiscoverer();

I've added flag -parameters to the library and all works as expected now. But it looks like it is not a best solution: sometimes there is no chance to change compillation flags it third party libraries =).

I hope it makes my proposal a bit clearer.

Thanks, Sergey

Comment From: snicoll

Thanks. In general, binding to third party is a smell as it does not give you the opportunity to document the properties, and it may expose additional property if the underlying object changes. Now that we've clarified the request is about a Spring Boot change, I am going to close this.

Constructor binding in Spring Boot requires the use of -parameters. I've noted that the doc is a bit outdated so I've submitted a PR to fix it, see https://github.com/spring-projects/spring-boot/pull/40157/files

Comment From: g-sg-v

In general, I didn't get why a usage of a property from a library to pass to the library smells somehow. Probably those properies are documented well, and if something will be changed in the library you will have to change only the property but not the class that reads properties, adapth properties and pass to the lib. Of course, the change in documentation makes sense but why not to change the code for better behavior (in fact it's even not change number of lines of code)? Anyway, decision is up to you. Thanks!

Comment From: snicoll

Of course, the change in documentation makes sense but why not to change the code for better behavior (in fact it's even not change number of lines of code)? Anyway, decision is up to you. Thanks!

It's a matter of responsibility and expectations (and the number of lines does not matter). If you want Spring Boot to consider the use case you've described, feel free to create an issue there. What I was pointing out is that it isn't a framework concern.