Bug 147000 - Dependent source roots are not re-scanned on modifications
Dependent source roots are not re-scanned on modifications
Product: java
Classification: Unclassified
Component: Source
All All
: P2 with 2 votes (vote)
: 6.x
Assigned To: Dusan Balek
: 125870 139274 161564 168737 (view as bug list)
Depends on:
Blocks: 121950
  Show dependency treegraph
Reported: 2008-09-11 22:33 UTC by Jesse Glick
Modified: 2009-08-06 15:28 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

Example of error badge not appearing (10.12 KB, text/plain)
2009-02-11 13:29 UTC, yrozijn

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-09-11 22:33:07 UTC
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.
Comment 1 Jan Lahoda 2008-09-17 14:48:49 UTC
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).
Comment 2 Jesse Glick 2008-09-19 03:02:32 UTC
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.
Comment 3 Jan Lahoda 2008-10-06 16:58:50 UTC
I am asking for a waiver for this issues. Reasons:
-high probability of nasty regressions
-probable performance issues
Comment 4 Jan Becicka 2008-11-13 09:17:18 UTC
*** Issue 125870 has been marked as a duplicate of this issue. ***
Comment 5 yrozijn 2008-11-23 14:16:37 UTC
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).
Comment 6 yrozijn 2008-11-23 14:20:37 UTC
I just noticed that undoing the changes, saving, redoing the changes, saving brings up all badges correctly in my case 
(within 1-2 seconds).
Comment 7 Jan Lahoda 2008-12-04 14:23:54 UTC
*** Issue 154016 has been marked as a duplicate of this issue. ***
Comment 8 tonynys 2009-01-06 07:02:17 UTC
Is this fixed in 7.0m1 release ?
Comment 9 Rastislav Komara 2009-02-03 10:56:11 UTC
Comment 10 Rastislav Komara 2009-02-09 10:04:29 UTC
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.
Comment 11 Rastislav Komara 2009-02-09 13:41:20 UTC
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.
Comment 12 Jesse Glick 2009-02-10 23:33:22 UTC
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.
Comment 13 yrozijn 2009-02-11 13:27:06 UTC
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.
Comment 14 yrozijn 2009-02-11 13:29:32 UTC
Created attachment 76854 [details]
Example of error badge not appearing
Comment 15 Jesse Glick 2009-02-11 15:12:45 UTC
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.
Comment 16 Rastislav Komara 2009-02-16 07:41:40 UTC
@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.
Comment 17 Jesse Glick 2009-02-18 03:23:45 UTC
"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?
Comment 18 Rastislav Komara 2009-02-18 08:16:01 UTC
@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() {

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.
Comment 19 Rastislav Komara 2009-02-18 08:18:06 UTC
Sorry, class C has to looks like:
class project.c.C {
   private project.a.B timeHolder = new project.b.B();
   void updateTimeHolders() {
Comment 20 Jesse Glick 2009-02-18 15:52:03 UTC
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.
Comment 21 Jiri Prox 2009-06-08 13:21:47 UTC
*** Issue 166377 has been marked as a duplicate of this issue. ***
Comment 22 Dusan Balek 2009-07-22 12:34:50 UTC
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).
Comment 23 Dusan Balek 2009-07-22 12:46:26 UTC
*** Issue 168737 has been marked as a duplicate of this issue. ***
Comment 24 Dusan Balek 2009-07-22 12:49:31 UTC
*** Issue 161564 has been marked as a duplicate of this issue. ***
Comment 25 Dusan Balek 2009-07-23 09:43:08 UTC
*** Issue 161564 has been marked as a duplicate of this issue. ***
Comment 26 ulfzibis 2009-07-23 10:23:43 UTC
> 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"
Comment 27 Dusan Balek 2009-07-27 12:53:00 UTC
First step implemented in jet-main. Adding an option to control level of dependencies re-scanning

Comment 28 Dusan Balek 2009-07-28 13:06:44 UTC
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.

Comment 29 Quality Engineering 2009-07-29 06:02:40 UTC
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).
Comment 30 Dusan Balek 2009-08-06 15:28:28 UTC
*** Issue 139274 has been marked as a duplicate of this issue. ***

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo