Community
Participate
Working Groups
Several actions related to Java code generation and refactorings (i.e. create method, create inner class, create field, generate getters/setters and some others) does not respect configured members sort order (Preferences -> Java -> Appearance -> Members Sort Order) and place new code just after current method or in the beginning of the class file. I believe the right approach will be to add new methods/classes/fields to the end of the particular member group (complete group list is available at "Members Sort Order" preference page). Several refactorings allow to choose insertion point. This dropdown should also set the default insertion point using the same rules above.
Move to JDT/UI.
Is it really UI? For me it sounds like something from the backend...
This is JDT/UI since we are coding backend stuff as well <g>. I agree with your comment. There are plans to improve the sorting capabilities and we decided to not change the refactoring/source manipulation code until we know how the new sorting feature will look like.
Any chance to get this feature implemented in 3.0.1 or 3.1 release?
Eugene, please don't change the target milestone field. We have this on the plan for 3.1 but it depends on how much effort has to go into J2SE 5.0.
Sorry, I wasn't sure about process. This is unclear when and how bugs in "resolved later" status will be picked up. Some of these over a year old and looks like forgotten.
Sorry for disturbing. I wonder if there is any estimate when this issue would be resolved.
There's no news yet. We are still covered with 5.0 issues which have priority.
Sorry, but this will not make it into 3.1.
We started doing that and it seems most refactorings already do. Can you file bugs against the features that don't?
(In reply to comment #10) > We started doing that and it seems most refactorings already do. Can you file > bugs against the features that don't? Really? I must be not using those most then. Extract method creates new private method right after method where it is extracted from andconvert anonymous class to nested always creates new class at the beginning of the class even if my sort order says to have them at the end.
The following refactorings does not respect sorting order: -- "Extract method" always put extracted method next to one where it is extracted from. I have private method at the bottom of the class -- "Convert anonymous class to nested" always put new class to the top of the class. I have nested types at the bottom of the class right after private methods. I just realized that member sorting order configuration can be defined on the project level...
The member sort order is only per workspace. It's main purpose is to specify the sort order in views (for example sort button in outline). Therefore we can't put that on a per project level. I filed bug 148544 for "Convert anonymous class to nested" and bug 148543 for Extract method. If you find more refactorings that randomly insert new elements, I'dbe happy if you could also file new bugs. This bug is too general and hard to track. The only thing we want to fix is that elements are entered next to elements of similar kinds. For example static methods next to static. If no element of the same kind is found, we use the member sort order to evaluate a good insertion point. Obviously, classes that don't follow the sort order themself might find the created element at some stranger place. We do not plan to enter the new method alphabetically.
(In reply to comment #13) > The member sort order is only per workspace. It's main purpose is to specify > the sort order in views (for example sort button in outline). Therefore we > can't put that on a per project level. Hmm. It sounds like another setting is needed to allow sorting for refactoring actions and such. So, that one can be made per-project. > The only thing we want to fix is that elements are entered next to elements of > similar kinds. For example static methods next to static. If no element of the > same kind is found, we use the member sort order to evaluate a good insertion > point. Obviously, classes that don't follow the sort order themself might find > the created element at some stranger place. > We do not plan to enter the new method alphabetically. I wasn't really looking for alphabetical sorting. Most annoying thing is that Eclipse refactorings are creating private methods in the middle of class. It would be really handy if those would be created at the end. So, it seems that searching for "same kind" probably should work from the end of the class and not from the current position. That would also help to deal with versionned resources since those will be easier to merge in case of conflicts.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
