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.
I applied the Import Management Tool to a file generated by the Form Editor, therefore, it contained guarded blocks. The form editor had generated an action method skeleton like: private void xxx(java.awt.event.ActionEvent evt) { // Guarded } // Guarded I filled in the body and then added another method between the guarded blocks yielding: private void xxx(java.awt.event.ActionEvent evt) { // Guarded ... } private void anotherMethod(File file) { ... } // Guarded Such that the closing curly brace for anotherMethod() is in a guarded block. In this situation, the Import Management Tool does not convert the parameter to anotherMethod even though it is writable. IMO, it should make this conversion. If not, it should at least warn me that there are changes it can't make and will leave my file such that it won't compile.
This is as designed. Guarded blocks in forms are exclusively managed and re-generated as whole by the Form Editor. Java module cannot mix in otherwise the changes would be ignored. File a RFE against form, if you want to change it. Even for Form, this behaviour is as designed.
Hmmm, I understand that the IMT can't change things that are in guarded blocks, but that's not the situation that was reported. In my case only the closing curly brace of the method is in a guarded block. The method definition is not in a guarded block and can be edited. Given this, I think this bug should be re-opened.
Import Management should change inside of skeleton method. I just tried it and it works-for-me. Do you really use 3.4 dev? There is similar issue #17503 fixed long time ago.
I was using a May 7 build. I just downloaded the May 24 build and tried again and the problem reproduces for me. Here are the steps: 1) Create a new JFrame. 2) Drop a button into the frame 3) Select the button, go to Events in the Property sheet and enter at handler for actionPerformed. I named it myActionPerformed. 4) Go to the Source Editor and change the skeletal actionPerformed handler to look like: private void myActionPerformed(java.awt.event.ActionEvent evt) { // Guarded System.out.println("myActionPerformed"); } private void method(File file) { file = new java.io.File("/dev/null"); } // Guarded Note that only two lines are guarded, the definition of myActionPerformed and the closing curly brace for method(). All the other lines were inserted between the guarded lines. 5) Add the import for File. At this point, the file should successfully compile. 6) Run the Import Management Tool and have it replace File with FQNs. It will remove the import statement but will not transform the parameter declaraton in method(), thereby converting a file that successfully compiles into one that does not.
Evan, sorry, I misunderstood the original report. You've caught me off-guard with splitting a guarded method in two... As Tomas says, IMT is able to work within such semi-guarded methods - but know that this style may be dangerous: you may easy loose the other method if you confirm deletion of myActionPerformed (e.g. when you delete the event handler from the handler list in Form).
Very good point about deleting myActionPerformed. I should avoid this style. While this IS a bug in IMT, it occurs when using a dubious style. I'm lowering the priority to a P4.
Thanks for the steps how to reproduce it. I followed them and it worked! I mean I was able to reproduce the bug. Accepting.
Set target milestone to TBD
Closing, Import Management Tool was replaced by Fix Import functionality.