Community
Participate
Working Groups
Created attachment 252844 [details] paper accepted by IEEE Transactions on Software Engineering When a software entity (e.g., a field) is renamed for some reason (e.g., correcting a typo), it likely that other related and similar entities should be renamed accordingly. Existing renaming tools, e.g., Visual studio and Eclipse, could not suggest developers to rename such related entities. To solve this problem, we have proposed an approach. The approach is presented in the attached paper which has been accepted for publication by IEEE Transactions on Software Engineering a few days ago. Our evaluation results (on open-source applications) show that the proposed approach is accurate in recommending entities to be renamed (average precision 82%) and in recommending new names for such entities (average precision 93%). Evaluation results also suggest that a substantial percentage (varying from 20% to 23%) of rename refactorings are expansible. We hope that this could be implemented by Eclipse although we have developed an prototype for Eclipse (available at http://sei.pku.edu.cn/~liuhui04/tools/rename/)
Once a rename refactoring is conducted, the proposed approach recommends to rename closely related software entities whose names are similar to that of the renamed entity. The rationale is that if an engineer makes a mistake in naming a software entity it is likely for her to make the same mistake in naming similar and closely related software entities
From the linked web page I take that you modified existing eclipse plug-ins, right? Don't you think the approach could be implemented as a separate plug-in on top of an unmodified JDT? Copying Marcel, because Code Recommenders might actually be the perfect home for such recommendations? Otherwise, and for now, JDT/UI would be the component we are talking about.
(In reply to Stephan Herrmann from comment #2) > From the linked web page I take that you modified existing eclipse plug-ins, > right? Don't you think the approach could be implemented as a separate > plug-in on top of an unmodified JDT? > > Copying Marcel, because Code Recommenders might actually be the perfect home > for such recommendations? > > Otherwise, and for now, JDT/UI would be the component we are talking about. Thanks for your quick response! We have change JDT to get notified once renamings are conducted recently. Detailed changes to JDT and LTK are listed in the attached document. Thanks. Thank you for your quick response! We have changed slightly the JDT and LTK to get notified once renamings are conducted. The changes are listed as follows: 1. Add a method (getJavaElement) to class org.eclipse.jdt.core.refactoring.descriptors.RenameJavaElementDescriptor public IJavaElement getJavaElement() { return this.fJavaElement; } 2. Add an interface (RenameListener) to package org.eclipse.ltk.core.refactoring public interface RenameListener { public void onRename(RefactoringDescriptor descriptor); } 3. Add a static field to class org.eclipse.ltk.core.refactoring.history. RefactoringHistory public static RenameListener renameListener = null; 4.Change method processHistoryNotification(IFileStore, RefactoringHistoryEvent, String) of class org.eclipse.ltk.internal.core.refactoring.history.RefactoringHistorySerializer (adding callback function) if (descriptor != null){ if (org.eclipse.ltk.core.refactoring.history.RefactoringHistory.renameListener != null) org.eclipse.ltk.core.refactoring.history.RefactoringHistory.renameListener.onRename(descriptor); }
