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 119962 - Refactoring fails if there's no space after initComponents() and variable declarations section
Summary: Refactoring fails if there's no space after initComponents() and variable dec...
Status: RESOLVED WONTFIX
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: All Windows XP
: P4 blocker (vote)
Assignee: Rastislav Komara
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-24 20:49 UTC by roger_rf
Modified: 2009-11-02 11:04 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description roger_rf 2007-10-24 20:49:02 UTC 
Hi,
I believe I've found a bug in NetBeans 6.0 Beta2. Try creating a new JInternalFrame through "File" > "New File" > "Swing
GUI Forms". The frame will be opened in Design view, so switch to Source view. NetBeans automatically includes two lines
after the initComponents() method, just before the variable declaration section. These two lines contain spaces, remove
these spaces so that you have only one line that contains no spaces. Now create a private field in your class ("private
String fooBar;"), right-click "fooBar" in the source code editor, click "Refactor" then "Encapsulate Fields...". In the
"Encapsulate Fields" dialog box, simply click "Refactor". The refactoring operation will fail silently. Now just try to
insert a single space in the line before the variable declaration section, call "Encapsulate Fields" again, and the
refactoring operation will work. This bug does not exist in NetBeans 5.5.1. Cheers,
Roger
Comment 1 Jan Becicka 2007-10-25 06:29:25 UTC 
Please attach messages.log
Comment 2 Jiri Prox 2007-10-25 09:09:23 UTC 
I can reproduce it as well. Message.log does not contain any exception. 
I'd say it's caused by the guarded blocks



Product Version: NetBeans IDE Dev (Build 20071024093841)
Java: 1.6.0_03-ea; Java HotSpot(TM) Client VM 1.6.0_03-ea-b01
System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Comment 3 Jan Becicka 2007-10-25 11:26:14 UTC 
There are 2 issues here.
1. Refactoring UI does not warn, if it is not possible to perform refactoring due to read only files or read only parts.
This is duplicate of issue 57518.
2. Java/source tries to insert code into guarded block, although it is possible to generate code into non-guarded parts.
Comment 4 roger_rf 2007-10-25 12:35:00 UTC 
It's like jiriprox said, messages.log doesn't contain any exception. I can attach it if you think it's really necessary.
Comment 5 Pavel Flaska 2007-10-31 12:13:27 UTC 
Reproducible in current trunk build.
Comment 6 Pavel Flaska 2007-11-01 11:27:56 UTC 
Generator test-case. It works, not sure what is wrong. Manually still reproducible.

IDE:-------------------------------------------------
IDE: [11/1/07 12:27 PM] Committing "GuardedBlockTest.java" started
Checking in GuardedBlockTest.java;
/cvs/java/source/test/unit/src/org/netbeans/api/java/source/gen/GuardedBlockTest.java,v  <--  GuardedBlockTest.java
new revision: 1.11; previous revision: 1.10
done
IDE: [11/1/07 12:27 PM] Committing "GuardedBlockTest.java" finished
Comment 7 Pavel Flaska 2007-11-01 11:36:22 UTC 
I've tested it more and I cannot reproduce GuardedException, but refactoring still does not work. Honza mentioned there
are two problems, reassigning back to get further evaluation from refactoring guys.
Comment 8 Jan Lahoda 2007-11-01 14:38:07 UTC 
Sorry Pavel, but I think that the problem is that the codegen still does not place the code at a perfect place - it
tries to insert the getter and setter at the very beginning of the first guarded line of variables, which cannot be done.

The reason why the exception does not appear seems to be that the Refactoring itself excludes modifications that would
throw the exception.

This usecase seems a bit artificial to me (as long as it works OK with at least one empty line) -> P4.
Comment 9 Pavel Flaska 2007-11-01 16:29:25 UTC 
Yes, that is something what comes to my mind too. I just went through it, but I tried to override method (suggested by
code-completion) at the same position and it worked correctly. Moreover, similar test passes.

> The reason why the exception does not appear seems to be that the Refactoring itself excludes modifications that would
> throw the exception.

If this is true, then you made the evaluation for refactoring guys and there is some difference in my test and in
code-completion example, which has to be investigated.
Comment 10 Rastislav Komara 2009-02-03 10:56:23 UTC 
Overtake.
Comment 11 David Strupl 2009-03-31 15:56:19 UTC 
Resolving all issues with milestone "future" as LATER. If you feel strongly that
it should be implemented please reopen and set the target milestone to "next".
Comment 12 Quality Engineering 2009-11-02 11:04:01 UTC 
NetBeans.org Migration: changing resolution from LATER to WONTFIX