Community
Participate
Working Groups
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.
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.
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.
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)
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!
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.
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.
(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.
Created attachment 199025 [details] Proposed patch + regression test Patch on top of BETA_JAVA7 branch.
Jay, This should go in 3.7.1 and hence the patch is on BETA_JAVA7 branch. Please review this patch.
(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.
Thanks Jay, Released in BETA_JAVA7 branch.
Verified.
