Open osmarleandro opened 3 years ago
This is a limitation of our implementation. When looking for PUSH_DOWN candidates, we enforce the signature of the method is the same. However, we don't deal with the case of replacing a parameterized type with a concrete type:
void customize(T factory)
void customize(ConfigurableReactiveWebServerFactory factory)
Thus, this refactoring ends up beeing incorrectly classified as a MOVE, as we allow changes in method signature when detecting MOVE..Hi @danilofes, thanks for your attention and support.
Considering the Java plugin, can the implementation be improved to detect generic types?
Summary
In the source code of osmarleandro/spring-boot@2787fad commit, I applied a single Push Down Method refactoring to customize() method in ManagementWebServerFactoryCustomizer class.
RefDiff detects a single Move Method refactoring, where the customize() method was moved to ServletManagementChildContextConfiguration class.
But, the ServletManagementChildContextConfiguration class has a nested class called ServletManagementWebServerFactoryCustomizer, which extends the ManagementWebServerFactoryCustomizer and receive the customize() method from the Push Down Method operation.
Code example
Diff fragment between the commit osmarleandro/spring-boot@2787fad and their parent.
Environment details
RefDiff 2.0
Steps to reproduce
Actual results
Expected results
A single instance of the Push Down Method refactoring applied to customize() method in ManagementWebServerFactoryCustomizer class.