Community
Participate
Working Groups
HEAD. When the type of parameter passed to a method in an invocation is changed, quick fix suggests changing the method signature to accomodate the changed parameter. Using this quick fix changes the signature of only the implementation of the method in the class of the receiver object. If the method has been implemented or overriden and there are other subclasses overriding it, it breaks the whole hierarchy, and results in a new method altogether. -----------------8<----------------------------------- package p; interface IBug { public void abc(String str); } class Bug implements IBug{ Object val; public void test(Bug b) { int str = 1; b.abc(str); // ERROR HERE. See quick fix } public void abc(String str) { System.out.println("hello"); } } class Bug2 extends Bug { @Override public void abc(String hello) { } } --------------------------8<---------------------------------- In the above example, the quick fix on the line b.abc(str) suggests changing signature of abc(String) to abc(int). But this only happens for class Bug. So now we have a new method abc(int) in Bug, and the hierarchy gets broken. My suggestion is to simply make it work like "Change method signature" refactoring and let it change method signatures everywhere in the hierarchy.
Quick fixes are intended to be quick fixes that just fix that specific problem by touching a limited amount of code. The user should have a chance to see what has been changed (in the Quick Diff ruler or in the preview from Ctrl+1). Instead of changing the existing quick fix, we should add a quick fix that invokes the Change Method Signature refactoring and initializes the dialog with the changed signature. That will also cover scenarios where method declarations and usages are spread over multiple files.
(In reply to comment #1) >[..] > Instead of changing the existing quick fix, we should add a quick fix that > invokes the Change Method Signature refactoring and initializes the dialog with > the changed signature. That will also cover scenarios where method declarations > and usages are spread over multiple files. I still have a doubt about this - won't two ways of fixing this problem be redundant and misleading? This is because in the cases such as those given in the above snippet, we know for sure that the method stands somewhere in the middle of a hierarchy which will definitely break if we just change the signature of one method. Hypothetical scenario - If the user has chosen the quick fix to change the signature, and is not abreast with the code i.e. basically he doesnt know that a particular method was overriding/implementing something else, he will exercise the current quick fix which doesnt invoke the refactoring, and when he does that, he'll end up with a new method. Yet, the code will still be correct and compile fine. He wont realize until he actually executes it!
*** This bug has been marked as a duplicate of bug 160212 ***
