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.
1. start latest dev build with clean userdir (Build 200302191044, JDK 1.3.1_06) 2. open ColorPreview 3. modify name of the class in editor to eg. ColoraaaPreview and press F9 You will get following error: error: cannot read: ...\ColorPreview.java If you press F9 again it usually works. The behaviour is often reproducible, but depends on the time between modification and press of F9. Related problem is that if you modify the class name in editor, the file is renamed in explorer, but backround parser annotates the class definition with error "Class ColoraaaPreview is public, should be declared in a file name ColoraaaPreview.java" what according to tab and explorer it is (it was done automatically). Saving file does not remove this error.
In the case you have described, the compiler was already launched (commandline constructed with "ColorPreview.java") - it was probably reading rt.jar & similar during the critical time - and then the parser reported class name change and the IDE renamed the source file.
Heeee...Are you joking? You rephrase the problem and close it as WONTFIX? Is it because of your bug count or because it cannot be solved? As you did not tell any details and I do not know the java module I cannot comment. But I would expect that it is you who is renaming the file and starting the compiler, so you should have this information and should be able to synchronize. I admit that it is not that serious error, because second compilation is OK. But second part of my report would be worth some investigation and some fix. Please consider reopening this issue.
If you evaluated the issue as a race b/w compiler and the rename tool triggered by the parser (compiler args constructed, then file renamed during compiler session) you failed to write it into the issue. In that respect, the comment is not a rephrase, but rather an evaluation. Similar race occurs whenever something is done to the file during external tool invocation running in background (compiler, exec, ...). Either such action must be denied or the compiler (or other ext process) aborted to solve your issue fully. Feel free to file relevant enhancement request against openide -- compile, delete, rename etc actions are defined there. BTW out of curiosity - what should happen in such situation ? a) abort compile (bad enough in itself) b) delay rename of the file (=> parser will report error, since class name != file name) c) hack in a special support for errors reported on classname != filename when a rename operation is delayed and compilation is underway (complicated and quite error-prone. The rename may be delayed significantly and the user might already moved her focus to another area - then suddenly a file gets renamed). Q: what other situations will cause race b/w external process and IDE ? Will there be hacks for each such situation ? As for automatic renames -- I have no opinion on whether the file rename should be done automagically, after user confirmation, or depending on a setting. Feel free to raise the issue on nbui@. The parser error you are describing is hard to reproduce for me (actually I was not able to reproduce it). Anyway, it is even less severe than the compiler issue because the data is only transient and are recreated after the file is reopened, or changed (of course errors should disappear after that). In fact, the parser reads the file, discovers name change (and reports an error), then the rename tool is triggered and it corrects the error. That document change (as any other document change) triggers another parse after 2 secs - no idea why that does not work in your case. Possibly we may need a intermediate state after the parser finishes, but before parser errors are reported to the user; autocorrection tools can then step in and correct the error (and trigger another parse) before the user gets confused by error underlinings. Again, feel free to file an enhancement request.
I'm not that much interested in this issue to discuss what is problem and what is enhancement and what is what. I saw a problem and wanted to help improve your module by telling you about it. Just randomly playing with this feature I can see several issues which seems to me to be bugs and which would deserve some investigation. For example in today's build (Build 030228, W2000, 1.3.1_06) the behaviour is a bit different. I started IDE with clean userdir, opened ColorPreview and modify class name to "ColoraaaPreview". The first problem is that file is not renamed in explorer. I do not know why, but it is just underlined in editor and "incorrect file for class" error is shown. Let say that's OK. If I open ColorPreviewBeanInfo and rename it to ColoraaaPreviewBeanInfo then the file is renamed and error I mentioned originally is not there anymore. The question is why the ColorPreview was not renamed as well? Second, in ColoraaaPreview you can see that also constructor is underlined that return value is missing. That's correct. Now close the file and do not save it (say not when asked for Save Change) and then reopen the file. The constructor and class is still underlined with the same errors, but there are no errors. Modifying class name does not have any effect on error on constructor and parser itself seem to be in some strange state - changing class name to something else is not reported as error anymore. Third, if you have still opened and renamed and modified ColoraaaPreviewBeanInfo try to close it and when asked for saving changes say "No". The filename will remain ColoraaaPreviewBeanInfo. Opening the file does not show any errors, but file is not compilable. All these problems I found just by playing with this feature for a few minutes. They are always reproducible on my machine. I'm not saying it is important defect. I think it is P4 as the rename of the class is not that frequent activity. What irritates me is your WONTFIX. However if QA thinks that it is non-issue I still in disagreement will respect that decision. If there are some problems in reproducibility of this issue just ask me and I will try to help you.
I tried to play with it and the result is issue 31777
Does it mean that everything else in this issue worked for you?
As for the error (cannot read): I understand that this is wontfix. This is minor issue (P5?). You have to press F9 right after class rename, right? As for the error annotations: I think this error should be fixed. Try to rename ColorPreview in the editor several times...you'll get parser annotation with tooltip "Class ColoraaaPreview is public, should be declared in a file name ColoraaaPreview.java" Svata told me to set target milestone to 4.0.
And what about renaming? Were you able to reproduce it? It still happens on my comp that some files are renamed and some others not when you change classname in editor.
I thought I wrote it. The parser annotation appears simply because class name is not the same as the file name after rename. I think, it could happen on every file, but not always.
Synchronization of changes in the editor (renaming the class name) and the explorer was replaced by Refactoring->Rename that can be called from Editor's context menu and provides better functionality and UI than the original functionality. It might be good idea to use Task list for tasks that can be postponed and doesn't require user attention. I filed Issue 45392. The rest of the bug is not reproducible anymore.
Reorganization of java component