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.

Bug 193183 - Tool for recovering from and diagnosing incorrect error badges
Summary: Tool for recovering from and diagnosing incorrect error badges
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 7.0
Hardware: All All
: P3 normal with 2 votes (vote)
Assignee: Svata Dedic
: 182530 (view as bug list)
Depends on:
Blocks: 121950
  Show dependency tree
Reported: 2010-12-09 17:53 UTC by Jesse Glick
Modified: 2013-09-02 14:21 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-12-09 17:53:17 UTC
Sometimes I am stuck with bogus error badges or other incorrect parser information on a project and I don't really know why. "Scan for External Changes" does not generally help since the problem does not usually arise from missed notification of file changes.

Restarting the IDE might help, but sometimes it doesn't. Deleting var/cache/index would work but then _everything_ needs to be rescanned, including completely unrelated projects, so this is a last resort.

The "incorrect error badge" detector sometimes works, but not very reliably. Sometimes it will resolve the error badge on just a couple of files but leave it on others; other times it won't resolve even the badge on the trigger file. And it is hard to convince it to run: have to close and then reopen every source file with an apparent error badge, or switch between files, etc.

What I want (perhaps in an experimental module?): a context menu item active on a project (perhaps also on a project multiselection) when

1. There is at least one error badge.

2. All source files in the project are marked as up-to-date according to FileBuiltQuery, meaning there is not a problem in the real world, just in the IDE's mind.

What it should do:

1. Compute the transitive dependency tree of the project.

2. Take a snapshot of the parser indices corresponding to those source & classpath entries, plus any other relevant information cached by java.source (e.g. SFBQ results).

3. Recreate everything snapshotted in #2 from scratch: call all queries again, and rescan all relevant source and binary roots incl. the JDK.

4. If that in fact results in at least some of the error badges going away, use the exception logger to submit a report consisting of the diff between #2 and #3 for future study. For example, if SFBQ returned a different result when called anew than the cached query result produced even after listening to changes, that can be tracked back to a failure to fire changes from some module. If the parser indices differ after a rescan, that may indicate a bug in how what gets rescanned in response to some kind of change. (If none of the error badges disappeared, the problem is likely a project misconfiguration.)
Comment 1 Jesse Glick 2010-12-09 17:55:42 UTC
*** Bug 182530 has been marked as a duplicate of this bug. ***