Bugzilla – Full Text Bug Listing
| Summary: | [encapsulate field] Code Style prefix causing problems refactoring | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Adam Brod <lothaar77-test> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
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. |
I have a code style prefix for fields (m_). If my class has a member field m_number, then can generate getters and setters (get/setNumber()) just fine. However, with the latest Eclipse RC7, there is a bug. If I do a refactoring to rename m_number to number, then the refactoring dialog asks me if I want to rename my getters and setters from get/setNumber() to get/setNumber(). Obviously these two are the same. Normally I just hit enter on that dialog popup to accept the defaults. If I do that, then I get an error telling me there is already a method called getNumber() and setNumber(). Obviously Eclipse should be smart enough to not rename my getter and setters if they already have the correct names. Eclipse 3.1 works fine, as I recall. Here is a test class that you can use to reproduce. First, you should set Preferences->Code Style->Code Templates with a Field prefix of 'm_'. Then in the class below, perform a rename refactoring on m_number to rename it to number. This should reproduce my problem. package test; public class SomeBean { private int m_number; public int getNumber() { return m_number; } public void setNumber(int p_number) { m_number = p_number; } }