This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Organize members reorders fields and enum values and causes compile errors and semantic changes | ||
---|---|---|---|
Product: | java | Reporter: | markiewb |
Component: | Hints | Assignee: | Svata Dedic <sdedic> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gtzabari, ralphbenjamin |
Priority: | P2 | ||
Version: | 8.0.2 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Shows the option in eclipse |
Increasing severity; hard to catch error is introduced, ordinal order is usually significant. I've decided to exclude the enum constants from reordering unconditionally: when created/generated, the new constants are introduced according to formatting/order settings. But Organize Members does should not change their order. Implemented in jet-main#9cf47c8e512e Integrated into 'main-silver', will be available in build *201501280002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/9cf47c8e512e User: Svata Dedic <sdedic@netbeans.org> Log: #249199: organize members will not change order of enum constants @Svata: There is still the issue with fields, which depend to each other public class NewClass { String b = "hello"; String a = b; } will be transformed into public class NewClass { String a = b; //<-- compile error String b = "hello"; } Will this be fixed too? I guess this must be optional, so a checkbox in the formatting options is neccessary. Eh, many apologies. I missed the 2nd case. Do you think the checkbox is necessary ? Reordering should not introduce compile errors at all. What is the use-case or scenario for changing the order - then fixing compile errors ? I mean when the computer assisted reordering is so helpful that the user is willing to fix code to be compilable again ? (In reply to Svata Dedic from comment #5) > Eh, many apologies. I missed the 2nd case. Do you think the checkbox is > necessary ? Reordering should not introduce compile errors at all. > > What is the use-case or scenario for changing the order - then fixing > compile errors ? I mean when the computer assisted reordering is so helpful > that the user is willing to fix code to be compilable again ? My usecase at work is: Most of our team members use eclipse. Their formatter/save-actions are configured the way that fields/enum values are not reordered. See the screenshot attached in the first post. When I use the organize members feature from NetBeans this introduces compile errors, which I have to fix manually. This means that I always have to revert the fields section via diff view to fix the errors and to reduce the number of diff chunks (for code review). So for my usecase it would be OK if fields will never be reordered. Sorry - I was referring to: (In reply to markiewb from comment #5 and comment #4) > Will this be fixed too? I guess this must be optional, so a checkbox in the > formatting options is neccessary. I am looking for a scenario when it is beneficial to turn reordering of fields ON regardless of possible compile-time errors introduced - or possibly I didn't understand the desired option's effect. (In reply to Svata Dedic from comment #7) > Sorry - I was referring to: > > I am looking for a scenario when it is beneficial to turn reordering of > fields ON regardless of possible compile-time errors introduced - or > possibly I didn't understand the desired option's effect. Ordering of fields may be a code style which is defined externally. For example by a code style guideline of a company/university/checkstyle. In this case the reordering would introduce errors, which is ok. Because this notifies the programmer that he his newly written code does not comply to the current code style. The 2nd case applies also to refactoring: if alphabetical sort is turned on, refactoring which moves several fields around whose init expressions depend on each other may also damage the source: fields are inserted according to coding style, but not in the order demanded by their dependencies. The behaviour is also triggered by "Sort members by Visibility" option. Option implemented in jet-main#1b16e5714385 Integrated into 'main-silver', will be available in build *201502110001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/1b16e5714385 User: Svata Dedic <sdedic@netbeans.org> Log: #249199: Member reorder can respect dependencies between fields and initializers. UI Option for code generator/ordering added. *** Bug 235658 has been marked as a duplicate of this bug. *** (In reply to markiewb from comment #8) > (In reply to Svata Dedic from comment #7) > > Sorry - I was referring to: > > > > I am looking for a scenario when it is beneficial to turn reordering of > > fields ON regardless of possible compile-time errors introduced - or > > possibly I didn't understand the desired option's effect. > > Ordering of fields may be a code style which is defined externally. For > example by a code style guideline of a company/university/checkstyle. In > this case the reordering would introduce errors, which is ok. Because this > notifies the programmer that he his newly written code does not comply to > the current code style. I don't understand this logic. Please explain again: why would we ever want code format to produce non-compiling code? (In reply to _ gtzabari from comment #14) > (In reply to markiewb from comment #8) > > (In reply to Svata Dedic from comment #7) > > > Sorry - I was referring to: > > > > > > I am looking for a scenario when it is beneficial to turn reordering of > > > fields ON regardless of possible compile-time errors introduced - or > > > possibly I didn't understand the desired option's effect. > > > > Ordering of fields may be a code style which is defined externally. For > > example by a code style guideline of a company/university/checkstyle. In > > this case the reordering would introduce errors, which is ok. Because this > > notifies the programmer that he his newly written code does not comply to > > the current code style. > > I don't understand this logic. > > Please explain again: why would we ever want code format to produce > non-compiling code? @gtzabari: Imagine my scenario: I am working in an eclipse dominated workplace. A given eclipse configuration like formatting and member sort order is mandatory for all developers. This configuration disables the ordering of fields (not methods). But in NetBeans the fields get reordered, when I call "Sort members" - even if I do not add/remove/update any field. The diff of the file for the code review now contains reorderings of parts I did not touch. But I want to keep the diff as small as possible. If I produce a compile error in the fields section by myself, then I will fix it by myself and I am responsible for the formatting/ordering in the fields section. @markiewb, So instead of "Sort uses dependencies" (as found at http://wiki.netbeans.org/NewAndNoteworthyNB81) it sounds to me like what you really want is the ability to disable member ordering altogether. Is that correct? I believe such a feature would make a lot more sense from a UI perspective than the ability to disable "Sort uses dependencies". (In reply to _ gtzabari from comment #16) > @markiewb, > > So instead of "Sort uses dependencies" (as found at > http://wiki.netbeans.org/NewAndNoteworthyNB81) it sounds to me like what you > really want is the ability to disable member ordering altogether. Is that > correct? > Filed an issue for that. https://netbeans.org/bugzilla/show_bug.cgi?id=251519 |
Created attachment 150953 [details] Shows the option in eclipse For example public enum NewClass { Z, Y, X } will be transformed to public enum NewClass { X, Y, Z } which changes the ordinality number, which results in bugs in existing code. -> Semantic change Similar issue for this example public class NewClass { String b = "hello"; String a = b; } will be transformed into public class NewClass { String a = b; //<-- compile error String b = "hello"; } which introduces a compile error. EXPECTED: Organize members should provide an option to exclude fields from ordering to prevent compile errors, like Eclipse JDT does (see attached screenshot) Product Version: NetBeans IDE 8.0.2 (Build 201411181905) Java: 1.8.0_20; Java HotSpot(TM) 64-Bit Server VM 25.20-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_20-b26 System: Windows 7 version 6.1 running on amd64; Cp1252; de_DE (nb)