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.
[release32 apr 6] "Needs compile" badge on Java sources seems to update at strange times. Often it is cleared about twenty seconds after compiling. I thought this was due to the folders not being refreshed after an external compilation (which would also be a bug in Java module's external compilers) but on one occasion I saw a class which I compile not change at all, and I waited for it and even manually refreshed the folder, to no effect. After hitting Compile on it again, however, it said that it was up-to-date, and cleared the badge. Note that in some circumstances the badge updates rather quickly. So I am not sure what causes it to wait this long at other times. Perhaps varies according to number of mounted sources??
Maybe the clue is, that during up-to-date checking, refresh() is explicitly invoked on individual FileObjects. Up-to-date checks are also performed when you hit Compile button. Also, whenever the External Compiler is given a filename, the IDE does refresh of the file's folder after the compiler completes its work (invoking refresh() on the apropriate folder's FileObject).
Sorry, Jesse, I couldn't find a reproducible case. If something has been done in filesystems with events, it might solve this issue as well.
Yeah, I am not sure how to reproduce either, though I think it still happens to me sometimes (at least the delays are random, sometimes very short, sometimes long). If the external compiler after finishing really correctly refreshed the folder, you would expect that the badge would update immediately after compiling. But it does not seem to work always. If I find out more I will reopen.
This is definitely still true, both in release32 final and in [dev may 19]. I saw it in dev-may-19 with nothing but sampledir mounted. As usual, after compiling the "needs to be compiled" badge stays on; if you hit Compile again (and says everything was up to date) the badge disappears at that time. If you do nothing, it will disappear after maybe ten or twenty seconds. In my r32 build (many things mounted), after changing some source and recompiling (external compiler - Jikes), sometimes the badge clears almost immediately; sometimes after five seconds; sometimes after ten; once not for thirty seconds, after which I selected Refresh on the folder to no effect, then I pressed Compile once again and it cleared immediately.
*** Issue 13133 has been marked as a duplicate of this issue. ***
Looks like P4 is not enough...
Confirmed; reproduction steps: - make file up-to-date - modify it in the editor - press F9. File gets saved, compiled, but the badge stays on. I cannot reproduce it reliably but from testing, it seems that file change events are not always delivered. In most cases, the change event is fired on the base XXX.class file, but not on XXX$1.class and XXX$2.class which are also watched for. In cases, when the badge did not disappear, no change event is fired. The change events are fired later, when I trigger "compile" once more; up-to-date check in the compiler does explicit refresh() on individual FileObjects, so maybe that wakes up the changes recognizer. Note that I am also intercepting changes to the set of files managed by the data object, no debug message was printed out about PROP_FILES change on the data object.
I use target folder when compiling - this seems to be the cause in my case. Regards Emmanuel
Actually it occurs when switching projects, irrespective of whether same or target folder used for compiling.
Reassigning to Radek - according to stacktraces, events are not always fired after refresh is called on a folder. Radek, please reassign the issue back, after you fix the event mechanism (or discover that it is irrelevant to this cause). Thanks.
Fixed in dev-trunk. All files which can be affected by the compilation are explicitly refreshed, not just folders.
[200109190100] Verified I'm not sure, if following behavior is correct or not: 1. Compile .java file (needs compile badge disappears) 2. Modify this file, but do not save. Badge appears -> is this correct, or badge should appear after save action? 3. Perform Undo -> Although editor shows, that file is not modified, needs compile badge is on.
oops, verified should not be above.
I think 2. is fine, the badge can appear immediately after edit. As for 3., I have not observed this; for me it works fine, i.e. after undoing the last edit to previously up-to-date file, the badge disappears again.
The 2nd is as designed (tm). The reason is, that if the file is modified in the editor so it will be saved before compilation anyway. The 3rd is a bug and I'll have it fixed.
Fixed in trunk.
Please help! I learnt some days ago that I can set how quickly the line number in the editor status line can be updated, when not using line numbers. Is there a way of setting the refresh option for this badge? Kind regards Emmanuel
It's refreshed as soon as the filesystem delivers the a notification that a file was changed. In fact, the compiler is _forcing_ refresh on affected folders/files before it says "Compile finished."
eh - the last reply meant: I have no idea - there's no timeout or threshold of updates and filesystems are required not to block change events as well. If you observe some strangeness (badges not updating after compile finishes), try to reproduce it, describe the environment (OS/VM version/IDE version will greatly matter in such case) and reopen the bug.
[200110030100] Verified
Resolved for 3.4.x or earlier, no new info since then -> closing.