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.

Bug 249199

Summary: Organize members reorders fields and enum values and causes compile errors and semantic changes
Product: java Reporter: markiewb
Component: HintsAssignee: 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

Description markiewb 2014-12-08 11:25:12 UTC
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)
Comment 1 Svata Dedic 2014-12-12 11:48:58 UTC
Increasing severity; hard to catch error is introduced, ordinal order is usually significant.
Comment 2 Svata Dedic 2015-01-23 17:06:55 UTC
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
Comment 3 Quality Engineering 2015-01-28 04:13:50 UTC
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
Comment 4 markiewb 2015-01-29 08:55:09 UTC
@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.
Comment 5 Svata Dedic 2015-01-29 09:04:38 UTC
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 ?
Comment 6 markiewb 2015-01-29 09:14:17 UTC
(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.
Comment 7 Svata Dedic 2015-01-29 09:22:58 UTC
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.
Comment 8 markiewb 2015-01-29 09:48:08 UTC
(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.
Comment 9 Svata Dedic 2015-01-30 08:34:19 UTC
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.
Comment 10 Svata Dedic 2015-02-02 11:09:48 UTC
The behaviour is also triggered by "Sort members by Visibility" option.
Comment 11 Svata Dedic 2015-02-02 13:33:24 UTC
Option implemented in jet-main#1b16e5714385
Comment 12 Quality Engineering 2015-02-11 03:34:39 UTC
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.
Comment 13 Dusan Balek 2015-03-11 15:23:43 UTC
*** Bug 235658 has been marked as a duplicate of this bug. ***
Comment 14 _ gtzabari 2015-03-23 17:19:28 UTC
(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?
Comment 15 markiewb 2015-03-23 19:16:37 UTC
(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.
Comment 16 _ gtzabari 2015-03-23 21:40:55 UTC
@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".
Comment 17 markiewb 2015-03-30 22:21:56 UTC
(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