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.
[#200508041800] 1.Create j2se project 2.Create JFrame form f1 3.Rename f1 to f2 4.Rename f2 to f3 The code is not compilable, the main method then looks like following: public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { new f2().setVisible(true); } }); f3 }
Reproducible according to provided steps.
I was doing the rename in Explorer by selecting java file node and invoking the refactoring from its context menu.
Seems that there was done change in source code and we applied our code changes to obsolete document. (Positions were incorrect.) Reassigning to form for further evaluation, as it is reproducible only with forms.
Reassigning back to java. We can hardly investigate why you don't have some positions up to date ;-). If you think that there is something incorrect in the form editor's behaviour then describe what exactly should be changed/should not happen.
I'm not sure, but remeber, that form was doing some changes in document during save operation. Is this still true?
The form editor seems to modify the files during the save operation. This seems to be a regression (this did not happen in 4.1) which also causes a deadlock (filed as a separate issue assigned to form).
> The form editor seems to modify the files during the save operation. Exactly, it is hard to store the data without making modifications to files ;-). I think you meant the document. Yes, we even modify the document. What's wrong with that? I don't see anything evil in that. Aren't you able to update positions (or whatever you want) when the file is saved? > This seems to be a regression (this did not happen in 4.1) which also > causes a deadlock (filed as a separate issue assigned to form). The deadlock was caused by another problem and has been already fixed.
*** Issue 62046 has been marked as a duplicate of this issue. ***
Problem is not in save operation, but in rename. During "rename refactoring" form module's listener is activated and starts to modify content of file. This is the evil :). Refactoring module provides API and SPI to allow other modules to participate in refactorings. But concurrent independent modifications of one file by two modules is definitely bad thing. It is a REGRESSION, because form module did not do this in previous versions. I tried to comment out regeneration of form files during rename and this bug dissapears.
Still reproducible on 050909 build.
Honza Stola has made some changes to correctly plug into refactoring. Not sure if it helps. Honzo, did you commit changes already?
Yes, it is in trunk, but the problem with incorrectly updated positions continues. Try the following scenario: 1. Create new JFrame called NewJFrame. 2. Add JButton. 3. Change text property of the button to take its value from a resource bundle and use 'org.openide.util.NbBundle.getBundle({sourceFileName}.class) .getString("{key}")' format in Resource Bundle editor. 4. Save the file, but leave it open. (the previous steps ensure that our GuardedBlockHandler will be invoked when this form will be renamed). 5. Rename the form to NewJFrame5. 6. When the refactoring is done switch to Source view and you will see public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { new NewJFrame().setVisible(true); } NewJFrame5 } Returning back to refactoring module to find out what else is wrong in form module and what should be rewritten to use their APIs to try to fix this issue :-/.
Problem is, that you must do your changes through java model. If you are unable to do changes through java model, you can use External Changes. See ExternalChange interface. You can also take a look at CommentRenameElement. Stop by our office for details. Anyway this issue has nothing to do with refactoring module.
Will try to close this issue before release of NB 5.0 ;-).
Fixed - the listener mentioned by jbecicka no longer exists in form module and the unsuccessful refactoring code has been removed (see issue 65193).
Verified in build of 2005-11-13.