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
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)
Created attachment 54934 [details]
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()
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.
And I believe that the IDE still runs with MasterFS enabled.
new revision: 1.21; previous revision: 1.20
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)