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: | Debugger doesn't stop at breakpoint on Windows | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jiri Skrivanek <jskrivanek> |
| Component: | Filesystems | Assignee: | rmatous <rmatous> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | mkubec, mmirilovic, pflaska, pjiricka, rmatous, tzezula |
| Priority: | P1 | ||
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | Stack trace. | ||
|
Description
Jiri Skrivanek
2008-01-11 08:30:35 UTC
Created attachment 54934 [details]
Stack trace.
adding Radek on cc (realted to changes in FS ?) The exception is thrown from masterfs. D:DevelopmentbuildsnbUserdir-20080111092113JavaApplication1build is just wrongly printed warning. SourceForBinaryQuery.findSourceRoots returns null because of external change. Definitely caused by #123542, but the source problem is that FS doesnt know about external changes. Please, evaluate. Evaluation: #123542 caused this as you pointed out, seems non compatible semantic change => reassigning back to openide. Anyway the java/j2seproject is not good candidate, the refresh is done after the ant script finished, which is not this case (the JPDA ant task is started before the finish). So the JPDA ant task should call refresh, right? Or do you want me to do so in the SFBQ and possibly other queries? Probably not, the code for refresh will need to be copied to every usage of FileUtil.toFileObject() which makes the usability of such an API much worse. Btw: here comes a part of the javadoc FileUtil.toFileObject() <cite> If you are running with the MasterFS module enabled, that will guarantee that this method never returns null for a file which exists on disk. </cite> And I believe that the IDE still runs with MasterFS enabled. /cvs/openide/masterfs/src/org/netbeans/modules/masterfs/filebasedfs/fileobjects/FileObjectFactory.java,v <-- FileObjectFactory.java new revision: 1.21; previous revision: 1.20 /cvs/openide/masterfs/test/unit/src/org/netbeans/modules/masterfs/filebasedfs/BaseFileObjectTestHid.java,v <-- BaseFileObjectTestHid.java new revision: 1.5; previous revision: 1.4 Guarantee is a guarantee, promise is a promise. We were ready to resign to it during discussion about it in the past just for this method call FileUtil.toFileObject and now should have been done. No implication for other methods issuing FileObject (without explicit promise) from FS API. Definitely for usage of FS API is still true (and since ever was): 1/ use FS API whenever possible for creating, deleting file, modifying content of file 2/ if you can't for any reason you must explicitly say it to FS API by calling refresh to sync it (on FS or FO) before the other code that might rely on your changes will be called. Here I'm going to add helper method FileUtil.refresh(File... files), that will refresh all files and its children recursively. In this case seems to me obvious that 1/ and 2/ were not satisfied fully. Definitely my commit fixes this problem. FYI additional checks, that FS must do to reveal all external changes isn't cheap and approximately the ratio is 100 checks for 1 capture external change (start with 1 opened J2SE project touches uselessly disk approximately > 300 times) For perf.team - this my commit shouldn't bring any regression in achieved perf. improvement (there was a little potential but probably not as big to justify broken documented contract) Verified. |