Bug 201682 - Adding method to NbTestCase triggers rescan of all test roots
Summary: Adding method to NbTestCase triggers rescan of all test roots
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 7.1
Hardware: Other Linux
: P3 normal (vote)
Assignee: Marian Mirilovic
Depends on:
Reported: 2011-09-06 12:42 UTC by Jaroslav Tulach
Modified: 2013-02-26 17:13 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2011-09-06 12:42:08 UTC
I've opened about 30 of NetBeans projects including nbjunit. I waited for parsing to finish. Then I've added new public method in NbTestCase.java:

    public void ruineIt() {

and the system started to reparse tests roots of all projects.
Comment 1 Jan Lahoda 2011-09-21 14:56:41 UTC
The root problem here, IMO, is that our indices only contain class-class relations (i.e. the IDE knows that class A uses class B in some way, but does not known that it uses method foo from class B). Recording the relations in full might be an overkill (note that these relations change a lot, and so the index might need to change non-trivially on almost each save). But having a full-text index might present a reasonable trade of.
Comment 2 Jan Lahoda 2011-09-26 10:39:49 UTC
The only solutions I can see are to either add a fulltext index, or somehow change the index structure*. Either of these is likely to lead into regressions in initial scanning, so I would like to ask for opportunity to defer it to next full release cycle.

*) Not sure how - I have some experience with index containing full information about used elements, and it (so far) seems to me that maintenance of such index would be too slow.
Comment 3 Jesse Glick 2011-09-26 19:05:57 UTC
I do not think this is P2 - the "workaround" is just to wait - and am not sure it is a DEFECT at all. You are changing the public signature of a very widely used class, and the IDE is checking whether there is any impact from that change, which is what it is supposed to do. Maybe it would be beneficial to have a differently organized index, maybe not; and any such reorganization could lead to numerous regressions in corner cases.
Comment 4 Jan Lahoda 2012-05-24 06:45:23 UTC
Changing to P3 as per jglick's explanation above.
Comment 5 Jan Lahoda 2013-02-26 17:13:35 UTC
If we improve the index, then we will automatically also improve the dependency detection. If we don't, it will remain as it is, accepting the reindexing may be slow in corner cases.