If I define a Converter with lambda or method reference, the project will fail to start due to the failure of parsing generics. I don't think that's reasonable, so after understanding the reasons, I modified it to support some of the above features

@Bean
public Converter<String, Integer> myConverter1() {
    return Integer::valueOf;
}

@Bean
public Converter<String, Integer> myConverter2() {
    return e -> Integer.valueOf(e);
}

Comment From: wilkinsona

Thanks for the pull request, @viviel. Could you please add some tests that illustrate the problem that you changes solve?

Comment From: viviel

OK, then I'll look at the CI problem

Comment From: wilkinsona

Thank you. Please don't worry too much about the CI failure. There's a known problem with the latest Spring Data snapshots that the Spring Data team are working on at the moment. A quick look at the test failures suggests that many, if not all of them, are related to that.

Comment From: viviel

Add test cases later

Comment From: philwebb

We might want to look at the logic in ConfigurationPropertiesBean when we merge this.

Comment From: wilkinsona

@viviel We're still hoping to merge this when we have the time to do so. Would you be interested in re-opening it?

Comment From: viviel

@wilkinsona I'm very sorry that I didn't pay attention to GitHub's email recently due to work reasons, so I didn't notice your message. If necessary and the master branch does not solve this problem, I am happy to continue trying to solve it. Re sort out the cause of this problem and the code logic of PR. By the way, resolve the conflict.

Comment From: wilkinsona

Thanks, @viviel. We'll see if we can merge this in 2.7.

Comment From: viviel

I'd like to talk about the plan I expected. You can see if it can be implemented in this way. If so, I'll re implement it from the branch of 2.7 and submit it.

I've combed the code these two days and found that there are similar problems with four interfaces: Converter, Formatter, Printer and Parser. My idea is to uniformly modify the four interfaces. The specific scheme is to make an adaptation layer for each interface, put the generic information in it, and then uniformly use the void addConverter(GenericConverter converter) method to register.

I'll implement it according to this scheme, and then you can see the specific code logic. If not, adapt the current changes to the code of the 2.7 branch