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.
Java debugger doesn't stop at breakpoint in java file on Windows. Maybe it is caused by changed in filesystems. It happens since build 200801090000. To reproduce: - create a java project - add breakpoint to Main.java - start debugger and it doesn't stop at breakpoint and exception is thrown WARNING: externally created folder: D:DevelopmentbuildsnbUserdir-20080111092113JavaApplication1build at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.findFileObject(FileBasedFileSystem.java:159) Product Version: NetBeans IDE Dev (Build 20080111054747) Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb) Userdir: D:\Development\builds\nbUserdir-20080111092113
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.