Bug 147000

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. ***

*** 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. ***