The misspelled method needs to be default and call the correctly spelled method not the other way around.
There is no way to NOT get a deprecation warning with the current code.
PR coming shortly.
Comment From: wilkinsona
I disagree. If the correctly spelled method was not default, its addition would be a breaking API change. Instead, you should mark your implementation of the deprecated method as @Deprecated.
Comment From: wilkinsona
Yes, of course. Please see https://github.com/spring-projects/spring-boot/pull/25400 for details of the thought that went into the change and the steps we took to ensure that it's backwards compatible. We cannot add a non-default method to an interface in a maintenance release as it will be a breaking API change.
Comment From: jmax01
Yes, of course. Please see #25400 for details of the thought that went into the change and the steps we took to ensure that it's backwards compatible. We cannot add a non-default method to an interface in a maintenance release as it will be a breaking API change.
Ah thanks I will just suppress the warning.
Comment From: jmax01
I would suggest adding to the Javadoc to minimize confusion.
As the user needs to implement intitialize (if not a lambda) but should call initialize.
Comment From: wilkinsona
Sorry, I'm not sure that I understand what you mean by "should call initialize". Bootstrapper is intended to be implemented by code building on top of Spring Boot, but it's Spring Boot itself that will call the Bootstrapper implementations. It calls initialize as encouraged by the deprecation of intitialize in favour of it.
Comment From: jmax01
I get that SpringBoot itself calls the properly spelled initialize, but the implementer of a Bootstrapper class must declare their method implementation with the wrong spelling AND suppress the the warning. This should be documented it is non-obvious.
Comment From: philwebb
This typo has caused a lot of pain. I think the updated code makes sense for people using lambdas, but it's not great for people directly implementing the interface. Short of documentation updates, the only solution I can think of is to introduce a new interface entirely. I've sketched something out in https://github.com/philwebb/spring-boot/tree/gh-25735.
Comment From: jmax01
@philwebb I love this solution, much more clear. One thing for sure I am going to really pay attention to my interface method names from now on, a miss spelling is basically unfixable.