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.
Here is the method I am trying to create via extract method: private String[] createCheckboxesForMultipleClasses(Collection<? extends GuiUtilsProvider> providers, String[] chkBoxIDs) { chkBoxIDs = createCheckboxesForMultipleClasses(providers, chkBoxIDs); return chkBoxIDs; } Netbeans wrote this. All I provided was the name of the method and the seection of code to be replaced. As you can see, it's a recursive call to itself. That's just wrong. The return value is also something NB thought up for no apparent reason. What NB should have done is created a method named what I named it with a body which is what I had highlighted at the time I used extract method. Beats me what is going on. It used to work just fine. Not sure if I've used Extract Method with *this* very download of the IDE or not. Here's your "about" : Product Version: NetBeans IDE 7.3 Beta 2 (Build 201211062253) Updates: NetBeans IDE is updated to version , NetBeans 7.3 Beta 2 Java: 1.7.0_05; Java HotSpot(TM) 64-Bit Server VM 23.1-b03 Runtime: Java(TM) SE Runtime Environment 1.7.0_05-b06 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb) User directory: C:\Users\bass\AppData\Roaming\NetBeans\7.3_userdir_extra Cache directory: C:\Users\bass\AppData\Roaming\NetBeans\7.3_userdir_extra\var\cache HTH
Here is the target behavior in pseudocode. It just treats the two parts of the if then else statements as statements unto themselves. original code: . . . if (condition) { do some huge thing ...blah blah blah for 200 lines } else { do some equally huge thing for 200 lines blah blah blah } . . . Goal state after refactor if (condition) processCondition() else processNonCondition(); private void processCondition() { do some huge thing ...blah blah blah for 200 lines } private void processNonCondition() { do some equally huge thing for 200 lines blah blah blah }
Pretty sure this *ought* to work as I described in the RFE. If-else statements are only nominally one statement. Semicolons define statement boundaries in Java AFAIK. Thus, this is two statements: if (true); else; and statements are the atomic units that extract-method refactoring operates upon. This is just my POV based on my understanding.
I tried to reproduce, but without any luck so far. It would be awesome if you could specify some kind of steps to reproduce and reopen. Thanks.
Created attachment 129938 [details] proof_1 matched pair matched pair of parens indicating statement bounds.
Hey having some trouble attaching images without losing this description so here is the description. It refers to attached images. The images are going to have to follow. Below are the steps to reproduce the bad behavior. Note that upon reading your response just now, I tried to create a very simple test class that showed the behavior and failed; I actually got a proper refactoring for an if-else statement in my simple test case. Therefore, it may not be an issue with very simple if-else statements or it may not be localized to if-else statements at all and that characterization of this behavior is just a red herring. At any rate, here are the steps to reproduce the bad behavior: Go to Netbean's source and locate the file CommonTestsCfgOfCreate in package org.netbeans.modules.gsf.testrunner. In that file, go to method private Component createCodeGenPanel() The third statement there begins with : if (multipleClasses) { for (GuiUtilsProvider provider : providers) { chkBoxIDs = new String[]{ provider.getCheckboxText("CHK_PUBLIC"), provider.getCheckboxText("CHK_PROTECTED"), provider.getCheckboxText("CHK_PACKAGE"), provider.getCheckboxText("CHK_PACKAGE_PRIVATE_CLASSES"), provider.getCheckboxText("CHK_ABSTRACT_CLASSES"), provider.getCheckboxText("CHK_EXCEPTION_CLASSES"), provider.getCheckboxText("CHK_SUITES"), provider.getCheckboxText("CHK_SETUP"), provider.getCheckboxText("CHK_TEARDOWN"), provider.getCheckboxText("CHK_BEFORE_CLASS"), provider.getCheckboxText("CHK_AFTER_CLASS"), provider.getCheckboxText("CHK_METHOD_BODIES"), provider.getCheckboxText("CHK_JAVADOC"), provider.getCheckboxText("CHK_HINTS") }; break; } } The first and last bracket above for a matched pair. This is shown by attached image: "proof_1". Highlight the code between and including that matched pair and invoke the refactoring. The refactoring accepts that statement as a valid target for refactoring and a dialog appears. This is shown by attached image proof_3. Type in the name myMethod into the refactoring dialog and hit it. Result: The highlighted target statement remains in place, unchanged. The method myMethod() is created with appropriate parameters and otherwise as described in my bug report- a recursive call to itself and a return value of checkboxIDs . This is shown in image: proof_4. HTH
Created attachment 129939 [details] refactoring invoked, target highlighted
Comment on attachment 129939 [details] refactoring invoked, target highlighted proof_3
Created attachment 129940 [details] proof_4 - recursive method created
Reopened, new reproduction details available
Thank you for the test case, should be OK after this patch: http://hg.netbeans.org/jet-main/rev/72e0ed3d5676
Integrated into 'main-golden', will be available in build *201301080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/72e0ed3d5676 User: Jan Lahoda <jlahoda@netbeans.org> Log: #224512: better handling of blocks being turned into new methods