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.
If a project is using Quick Run, there is no real purpose in displaying the out-of-date badge on the icons of its *.java files - they will rarely be built to build/classes/ anyway. Not sure what fix to recommend. Possibilities: 1. Get rid of the OOD badge generally: make JavaNode no longer call FileBuiltQuery, and remove impls from project types. 2. Make projects supporting CoS suppress their FBQ (or make it always return "up to date") when CoS is enabled.
I suspect the OOD badge is useful in small projects only. In small projects, CoS should work reliably, so those users probably won't turn it off. For big projects with custom Ant scripts, I don't think the OOD badge is really useful. So even if they turn CoS off, users wouldn't miss the OOD badge. This is my thinking about Java SE projects mostly. I'm not sure about other project types.
For module projects, the badge can be useful in telling you whether you need to build the project after some changes. Quick Run can be used to run unit tests in many cases, but you still need to do a build to make the JAR and other artifacts for running the real platform. Of course it might be nice for the Ant build to be run automatically when you save changes to sources, in which case you would not need the badge.
CoS is not always instantaneous (large refactorings, heavy CPU load etc.), so it would be helpful to have visual feedback when CoS is up-to-date for a particular source file. Even when CoS is quasi-instantaneous, it would be nice to have a visual indication that this is so.
Even if the file does not get compiled immediately after the save, it should not matter - Quick Run (Debug, etc.) will anyway wait for all outstanding files to be compiled before starting the program, so the user need not be paying attention to this. Perhaps there is some other reason why you would want to know when the background compilation finished for a particular file?
You are right that it should not matter for the "correctness" of the invoced actions, but seeing the progress and state of CoS would be reassuring for the user, and may be helpful in cases where there's some problem with CoS, or cases like turning on and off CoS for the project. Ideally, in my opinion, it should not matter whether compilation is triggered automatically by CoS or manually by the user (the latter currently only being possible when CoS is turned off); the compilation itself should be the same for both, and hence its state should be indicated in the same way.
The CoS, Build/Compile Single and out-of-date badges work this way currently: -before a project is executed for the first time, Build action executes the ant based build action. The out-of-date badges are therefore meaningful here. -when the project is executed (in the CoS way), the classes in build/classes are kept up-to-date, and the out-of-date badges are never shown.
Agreed, I think it is OK the way it works now.