| Summary: | [move method] Move method refactoring handles a method call leads to behavioral change | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Gustavo Soares <gsoares> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jongwook.kim, markus.kell.r |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
*** This bug has been marked as a duplicate of bug 154851 *** Sorry, wrong dup. In a way, it's your fault because you decided to move the method to b but didn't ensure that b is not null.
You don't even need an intermediate method to reproduce:
public class A {
public B b;
protected void k() {
}
public static void main(String[] args) {
new A().k();
}
}
class B {
}
I don't have good idea how we could detect or prevent this problem in general. Do you have a suggestion? We could just add a static note to the dialog, telling that the user has to ensure that the target is never null.
Hi Markus, A note about that seems a good advice to the user. Indeed this advice is related to a precondition for the move method refactoring I found in a PhD thesis of Marcio Cornelio: B != null is an invariant of A. (In reply to comment #3) > In a way, it's your fault because you decided to move the method to b but > didn't ensure that b is not null. > > You don't even need an intermediate method to reproduce: > > public class A { > public B b; > > protected void k() { > } > > public static void main(String[] args) { > new A().k(); > } > } > > class B { > } > > > I don't have good idea how we could detect or prevent this problem in general. > Do you have a suggestion? We could just add a static note to the dialog, > telling that the user has to ensure that the target is never null. *** Bug 424388 has been marked as a duplicate of this bug. *** This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build Identifier: 20090920-1017 The move method refactoring tool changes a method call to avoid compilation error but leads to behaviral change. After the refactoring, a nullpointerexception is thrown on the program. Reproducible: Always Steps to Reproduce: 1. Create the classes: public class A { public B b; protected void k() { } public void test() { k(); } public static void main(String[] args) { new A().test(); } } public class B { } 2. program execution leads to normal behavior. 3. Apply the move method refactoring to k moving it to B. public class A { public B b; public void test() { b.k(); } public static void main(String[] args) { new A().test(); } } public class B { protected void k() { } } 4. After the refactoring, program execution leads to java.lang.NullPointerException exception