Community
Participate
Working Groups
The JDT rename type refactoring has the option to "Update similarly named variables and methods". When checked, it will basically perform two kinds of refactorings: 1) rename the type 2) rename all corresponding fields with a similar name as the type Participants can take part in both refactorings. The problem is that the participants for the second (field) refactoring are loaded and initialized for the IType being renamed and correspondingly get a RenameTypeArgument, while in fact they are supposed to handle the renaming of IField elements. So "normal" rename-field participants can not participate in this refactoring. In order to become involved, they have to be additionally enabled for IType elements and then use internal JDT API to figure out which elements are to be renamed, and what are the new names. It would be much simpler of they would get loaded and initialized for the actual fields being renamed. See this stacktrace where the loading of our RenameFieldParticipant occurs (as a workaround, we enable it for IType and use internal JDT API, as mentioned): Thread [ModalContext] (Suspended (breakpoint at line 43 in RenameFieldParticipant)) RenameFieldParticipant.<init>() line: 43 NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method] NativeConstructorAccessorImpl.newInstance(Object[]) line: 57 DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 45 Constructor<T>.newInstance(Object...) line: 526 Class<T>.newInstance() line: 379 EquinoxRegistryStrategy(RegistryStrategyOSGI).createExecutableExtension(RegistryContributor, String, String) line: 184 ExtensionRegistry.createExecutableExtension(RegistryContributor, String, String) line: 905 ConfigurationElementMulti(ConfigurationElement).createExecutableExtension(String) line: 243 ConfigurationElementHandle.createExecutableExtension(String) line: 55 ParticipantDescriptor.createParticipant() line: 85 ParticipantExtensionPoint.getParticipants(RefactoringStatus, RefactoringProcessor, Object, RefactoringArguments, IParticipantDescriptorFilter, String[], SharableParticipants) line: 98 ParticipantManager.loadRenameParticipants(RefactoringStatus, RefactoringProcessor, Object, RenameArguments, IParticipantDescriptorFilter, String[], SharableParticipants) line: 74 RenameModifications.loadParticipants(RefactoringStatus, RefactoringProcessor, String[], SharableParticipants) line: 193 RenameTypeProcessor(JavaRenameProcessor).loadParticipants(RefactoringStatus, SharableParticipants) line: 41 RenameRefactoring(ProcessorBasedRefactoring).checkFinalConditions(IProgressMonitor) line: 233 CheckConditionsOperation.run(IProgressMonitor) line: 85 CreateChangeOperation.run(IProgressMonitor) line: 121 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2313 WorkbenchRunnableAdapter.run(IProgressMonitor) line: 87 ModalContext$ModalContextThread.run() line: 122
Moving to JDT UI for comments
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. If you have further information on the current state of the bug, please add it. 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.
