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

Bug 350885

Summary:

[Search] The pull up refactoring throws an NPE when pulling up a member that already exists in the superclass

Product:

[Eclipse Project] JDT

Reporter:

Mohsen Vakilian <reprogrammer>

Component:

Core

Assignee:

Satyam Kandula <satyam.kandula>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

amj87.iitr, jarthana, markus.kell.r, nchen, raksha.vasisht, reprogrammer, snegara2

Version:

3.7

Flags:

jarthana: review+

Target Milestone:

3.7.1

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
The screenshot of the expected error dialog	none
The error log that Eclipse produces for pull up refactoring	none
Workspace containing a Java project that demonstrates the bug in the pull up refactoring.	none
Proposed patch + regression test	satyam.kandula: review?

Description Mohsen Vakilian

2011-06-30 17:34:28 EDT

Build Identifier: 20110615-0604

While working on CodingSpectator <http://codingspectator.cs.illinois.edu/>, we encountered a bug with pull up refactoring. The problem happens when the user tries to pull up a method "m" from to a super class that already contains a method called "m". The expected behavior is to warn the user about the existing method in the super class. But, the actual behavior is to throw an exception and report the problem in the error log.

We reproduced this bug in the following environments.

1. Eclipse Helios on Linux
2. Eclipse Indigo on Linux
3. Eclipse Indigo on Mac

However, we couldn't reproduce this problem when running Eclipse Helios on Mac. Eclipse Helios on Mac shows a dialog with the following message and doesn't throw any exceptions or report anything to the error log.

  Method 'm' (with the same signature) already exists in type 'edu.illinois.codingspectator.Parent', which will result in compile errors if you proceed.

Reproducible: Always

Steps to Reproduce:
1. Create a Java Project. Add a Java file with the following contents to the project.

  class Parent {
    void m() {
    }
  }

  class Child extends Parent {
    void m() {
    }
  }

2. Select method "m" from class "Child". Then, invoke Refactor > Pull Up...
3. Click Finish on the Refactoring dialog. Clicking the Finish button will result in opening a dialog with the following message.

  An unexpected exception occurred while performing the refactoring. See the error log for more details.
  See the error log for more details.

Comment 1 Mohsen Vakilian

2011-06-30 17:36:40 EDT

Created attachment 198937 [details]
The screenshot of the expected error dialog

This attachment is the screenshot of the expected error dialog. We only got this error message when running Eclipse Helios on Mac. On every other platform that we tried, Eclipse reported an exception in the error log.

Comment 2 Mohsen Vakilian

2011-06-30 17:38:09 EDT

Created attachment 198938 [details]
The error log that Eclipse produces for pull up refactoring

This attachment is the error log that Eclipse produces when the user invokes the pull up refactoring as described in this bug report.

Comment 3 Markus Keller

2011-07-01 06:29:12 EDT

I could not reproduce on Windows 7 and Linux.

I don't think this is OS dependent. It rather depends on other code in your workspace. The NPE happens in a search for references to the pulled-up method.

Moving to JDT Core. It's probably easiest to investigate backwards from there to find the condition leading to the NPE.


Caused by: java.lang.NullPointerException
	at org.eclipse.jdt.internal.core.search.IndexSelector.getQualifiedNames(IndexSelector.java:308)
	at org.eclipse.jdt.internal.core.search.IndexSelector.initializeIndexLocations(IndexSelector.java:208)
	at org.eclipse.jdt.internal.core.search.IndexSelector.getIndexLocations(IndexSelector.java:276)
	at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.selectIndexes(JavaSearchParticipant.java:107)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.getIndexes(PatternSearchJob.java:79)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.ensureReadyToRun(PatternSearchJob.java:50)
	at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:174)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:214)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584)

Comment 4 Ayushman Jain

2011-07-01 06:40:27 EDT

Mohsen, since the bug is not reproducible with a minimal test case u posted in comment 0, will you be able to share your workspace? Or create a reproducible testcase independent on your workspace?

Satyam, please follow up. Thanks!

Comment 5 Mohsen Vakilian

2011-07-01 10:24:49 EDT

Created attachment 198969 [details]
Workspace containing a Java project that demonstrates the bug in the pull up refactoring.

This attachment is a snapshot of a workspace after the pull up refactoring has thrown an NPE. The workspace simply contains a Java project with a single Java class as described in the issue.

Comment 6 Mohsen Vakilian

2011-07-01 16:08:20 EDT

I figured why you couldn't reproduce the problem. I should have provided you with one more piece of information. In my instructions for reproducing the bug, I just said to create a Java file containing the following.

  class Parent {
    void m() {
    }
  }

  class Child extends Parent {
    void m() {
    }
  }

It looks like the name of the Java file is important. If the name of the Java file is "Parent.java", the bug won't show up. But, for instance, if the name of the Java is "C.java", the bug will show up.

Comment 7 Satyam Kandula

2011-07-04 00:25:34 EDT

(In reply to comment #6)
> I figured why you couldn't reproduce the problem. I should have provided you
> with one more piece of information. In my instructions for reproducing the bug,
> I just said to create a Java file containing the following.
> 
>   class Parent {
>     void m() {
>     }
>   }
> 
>   class Child extends Parent {
>     void m() {
>     }
>   }
> 
> It looks like the name of the Java file is important. If the name of the Java
> file is "Parent.java", the bug won't show up. But, for instance, if the name of
> the Java is "C.java", the bug will show up.
Thanks, I am able to reproduce the problem. Search is having problems if the focus java file doesn't have a class with the name of the java file :(. If "Build Automatically" is not checked, one will not run into the problem and I guess that is the reason that it works fine in MAC.

I will look into the problem.

Comment 8 Satyam Kandula

2011-07-04 02:38:07 EDT

Created attachment 199025 [details]
Proposed patch + regression test

Patch on top of BETA_JAVA7 branch.

Comment 9 Satyam Kandula

2011-07-04 02:41:26 EDT

Jay, This should go in 3.7.1 and hence the patch is on BETA_JAVA7 branch. Please review this patch.

Comment 10 Jay Arthanareeswaran

2011-07-04 10:45:56 EDT

(In reply to comment #9)
> Jay, This should go in 3.7.1 and hence the patch is on BETA_JAVA7 branch.
> Please review this patch.

+1 for the patch.
Reviewed/tested against BETA_JAVA7.

Comment 11 Satyam Kandula

2011-07-05 10:15:46 EDT

Thanks Jay,
Released in BETA_JAVA7 branch.

Comment 12 Raksha Vasisht

2011-07-20 03:34:54 EDT

Verified.