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 had projectimport.eclipse.{core,j2se,web} open. I deleted a public method from .core which was used from the others. I think I had the file using it in .j2se open already, and fixed that file. But no error badge appeared on the .web project. I had to go and open the file in .web that I knew used the method - at which point its parse status in the editor showed an error, though there was no badge on the file or project yet. Later an error badge appeared on the project. It would be better to turn error badges off entirely if they do not work. It is even better to have them appear when they should not, than not to appear when they should - as this bug means that you think you have made your code compilable when really it is still broken.
Hm, the main problem here is performance - it may take a while to recompute all the dependencies (when I have java.hints+deps. open, commenting-out a method in FileObject recompilation takes ~50 seconds).
Even in this (extreme) case, I would rather the IDE tell me 50 seconds later that I made a mistake, while I can still correct it cleanly, rather than not tell me at all and have me waste much more time later breaking a build and trying to diagnose and fix it.
I am asking for a waiver for this issues. Reasons: -high probability of nasty regressions -probable performance issues
*** Issue 125870 has been marked as a duplicate of this issue. ***
I don't think this is a performance issue. In my ~100 class project, I usually get all error badges where they should be. But sometimes a change won't bring up error badges at all. When I make another change, I get all badges as they should, within 2 seconds. Instead of turning off badges entirely, I think a function like "rescan entire project" would be a better workaround (probably with a progress bar and everything).
I just noticed that undoing the changes, saving, redoing the changes, saving brings up all badges correctly in my case (within 1-2 seconds).
*** Issue 154016 has been marked as a duplicate of this issue. ***
Is this fixed in 7.0m1 release ?
Overtake.
If I understand problem correctly, there is problem with updating error badges on project depending on project with compilation errors. Or in general problem when project A changes and cause compilation errors on project B. From my investigation the dependency between projects is managed by depending on resulting jar-file of project A compile process. In this case there is need to lunch compilation of project A and then rescan project B depending on change of A.jar-file. Did I understand problem correctly? Thank for info.
This issue requires recompiling of ALL projects included in dependency graph. The time estimation of this task is O(2n+log n) [where n is number of all files included in dependency graph] which makes it impossible for larger sets of files/projects. In case like NetBeans this task can take from tens' of minutes to hours to finish. This issue should be fixed in future when there will be enough processing power.
You should only need to check for problems in files which referred to the class where the change was made, which will usually limit the scope pretty well. Rescanning "all of NetBeans" because you made some change to e.g. org.openide.util.Utilities could indeed take some time, but it is unlikely that the IDE user would have every NB module project open simultaneously, and we generally limit the scope of all refactoring operations to open projects (for better or worse). I still disagree that "rescanning could be slow" is an excuse for not updating the error badges when they may be wrong, for the reasons I gave on Sep 19 2008. Correctness should be the top priority. At a minimum, if the IDE is not going to ensure that error badges are correct, it should mark all open projects with a '?' icon or similar to warn you that it has no idea whether things are broken, and offer some way to trigger a rescan. The current behavior is worse than nothing - the IDE leads you to believe that error badges help you remember what needs to be fixed, but in fact you cannot depend on this and need to use Ant clean builds before committing anyway. Note that in Eclipse, if you save a breaking change, broken clients are shown as errors without you needing to take any further action - even if the client is in a different project. BTW I have noticed all sorts of error badge problems in recent dev builds. There does not seem to be any reliable correspondence between whether (a) the editor tab is badged, (b) the file node in Projects is badged, (c) there is an underlined error in the editor, (d) there is an actual error. In particular, when making an incompatible change in one file and updating usages in other files, then saving, badges do not refresh reliably at all. If I can manage to reproduce I will file.
I agree with jglick. Today I stumbled upon a reproducible case where error badges don't appear where they should, but I'm sure there are other (irreproducible) cases too. I'll attach an example project.
Created attachment 76854 [details] Example of error badge not appearing
yrozijn: this issue report is specifically about the fact that the Java infrastructure _intentionally_ does not attempt to update error badges across distinct projects. Your test case is within a single project, which is intended to work, so please file a separate DEFECT issue and make it block the umbrella issue #121950.
@jglick: I play a while with eclipse and your statement is wrong. Eclipse does not check errors deeper then one level of dependency. If you have A<-B<-C and you break A the B is marked as broken but not C which depends on broken B. So in this case are error badges wrong. The complexity of problem is not in scanning opened files one depth in dependency graph, but full rescan of dependency graph to ensure the badges are put there correctly. Unfortunately, I must hold my opinion and be extremely skeptic about time intensity of this task.
"If you have A<-B<-C and you break A the B is marked as broken but not C which depends on broken B." - that's exactly what I would expect. The actual usage in B which is broken by the change in A gets marked as an error. I don't care if C depends on B, because I do not need to fix C. Or perhaps you are talking about some more specific scenario?
@jglick: Yes. By breaking B a also break C but there is no error badge. consider this situation: interface project.a.A { void setTime(Date date);} class project.b.B implements project.a.A { void setTime(Date date) { this.date = date;} } class project.c.C { private project.a.A timeHolder = new project.b.B(); void updateTimeHolders() { timeHolder.setTime(now()); } } Now rename or change method signature in project.a.A.setTime(Date date) to whatever. The B is marked as error but not C. and C is broken To because there is dependency on broken class. In eclipse if you resolve problem in B then problem in C will be marked. In general, the workspace does not compile because of problem in B.
Sorry, class C has to looks like: class project.c.C { private project.a.B timeHolder = new project.b.B(); void updateTimeHolders() { timeHolder.setTime(now()); } }
Indeed I can reproduce this in Eclipse: package a; public interface A { void m1(); } package b; public class B implements a.A { public void m1() {} } package c; public class C { {new b.B().m1();} } Changing A.m1 to m2 does not mark C.java as erroneous. But this is correct. If you treat dependencies at the binary level, c/C.class is still valid relative to the signature of b/B.class, since it declares invokevirtual #13; //Method b/B.m1:()V and makes no mention of a.A at all. Similarly, at the source level, since B.java still declares a public void m1(), C.java is not "broken", any more than if there were an unrelated compilation error somewhere else in B.java. Either way, I don't think this would be considered a problem by Eclipse users. What counts is that B.java is initially marked as in error, so you know you need to fix something - and if you fix it by renaming m1 to m2 in B.java, as opposed to say adding m2 but keeping m1, then C.java will then be marked as in error too. NetBeans fails to do any of this correctly, and that is a serious bug.
*** Issue 166377 has been marked as a duplicate of this issue. ***
Reopening. The problem becomes fatal with Compile on Save turned on. We should try to implement rescanning of dependent project (and put it at least on option that should be ON when CoS is ON).
*** Issue 168737 has been marked as a duplicate of this issue. ***
*** Issue 161564 has been marked as a duplicate of this issue. ***
> We should try to implement rescanning of dependent project I'm afraid, that this could make CoS very slow in special cases. (maybe have 2-step limit for source paths inside/outside current project) What about having dialogue after run action: "Dependent source path [projectName:pathName] had changes | causes errors" "First compile all Dependencies" "Run old State"
First step implemented in jet-main. Adding an option to control level of dependencies re-scanning (Tools->Options->Editor->Tasklist) http://hg.netbeans.org/jet-main/rev/05c371bed4d1
Second step: Marking dependent roots that are not immediately re-scanned on modification as 'dirty'. 'Dirty' roots are re-scanned when necessary (e.g on project run). Fixed in jet main. http://hg.netbeans.org/jet-main/rev/dc3a26fe2abf
Integrated into 'main-golden', will be available in build *200907290201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/dc3a26fe2abf User: Dusan Balek <dbalek@netbeans.org> Log: Marking dependent roots that are not immediately re-scanned on modification as dirty (see issue #147000).
*** Issue 139274 has been marked as a duplicate of this issue. ***