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.
Summary: | Move waitScanFinish into TestUtil | ||
---|---|---|---|
Product: | java | Reporter: | Andrei Badea <abadea> |
Component: | Source | Assignee: | Tomas Zezula <tzezula> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | Keywords: | T9Y |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 122852 |
Description
Andrei Badea
2007-11-01 17:44:26 UTC
Marking as defect because this also delays JavaSource user action tasks without user feedback that there is a scan in progress, as seen in issue 122852. These methods are inherently unsafe (their semantics does not guarantee that the background scan does not start right after the method returned). Moreover, waitScanFinished is deprecated. Please use runWhenScanFinished, which is a supported method. Quoting from desc1: "proved by a task passed to JavaSource.runWhenScanFinished() not being executed synchronously" I'm obviously using runWhenScanFinished(). I'm also talking about tests, where I control the events and there is no way for the Java infrastructure to start running again. Tomasi, please take a look at it. Thanks It was actually caused by race condition the SU.wSF can caused. The method shouldn't be used in code but it may sense to create similar barrier method in the TestUtil. There is also call for: TestUtil.setIndexFolder() TestUtil.scheduleAndWait() TestUtil.setEnableLibraries() Even if I forgot something, it's on the Andrei's board, so he can check ;-) Fixed: cc7257880f67 > ... it's on the Andrei's board, so he can check ;-)
He has checked. Looks very good, thanks!
|