Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313918

Summary: [move method] Move method refactoring handles a method call leads to behavioral change
Product: [Eclipse Project] JDT Reporter: Gustavo Soares <gsoares>
Component: UIAssignee: 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

Description Gustavo Soares CLA 2010-05-21 10:39:12 EDT
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
Comment 1 Markus Keller CLA 2010-05-21 11:37:39 EDT

*** This bug has been marked as a duplicate of bug 154851 ***
Comment 2 Markus Keller CLA 2010-05-21 11:39:30 EDT
Sorry, wrong dup.
Comment 3 Markus Keller CLA 2010-05-21 11:50:59 EDT
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.
Comment 4 Gustavo Soares CLA 2010-05-21 19:10:40 EDT
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.
Comment 5 Martin Mathew CLA 2013-12-18 22:11:25 EST
*** Bug 424388 has been marked as a duplicate of this bug. ***
Comment 6 Eclipse Genie CLA 2020-03-16 10:33:42 EDT
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.