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.
After you clean your project the omni-degugger cannot be used any more. 1) Create new J2SE application 2) OmniDebug file Main class (created by default) 3) Clean up Project (project context menu -> Clean project) 4) try step 2 -> Can't you must compile before - OK 5) Compile (either single class or whole project) 6) try step 3 -> Can't you must compile before - wrong So far I came to this - once a (j2se)project is cleaned and you try to call cp.findResource() (o.n.m.omnidebugger.Debug#line_132) it will always return null even if the classfile exists on the disk. It seems to be slightly RANDOM but happens to me quite often (90%?). Should be easy to reproduce. I would say this is bug in ClassPath or MasterFS. But I'm not sure if the approach CP.findResource() is legal in all context. E.g. if you do not need to listen on something or refresh/ping the project somehow... Actually I have the more or less the same problem in my module :)
Step 6 should be (s/3/2): 6) try step 2 -> Can't - you must compile before - wrong
Indeed, ClassPath.findResource uses obsolete cached results if you have never attached a listener to it! Pretty dumb. Fix is easy once discovered. But I will change omnidebugger to not rely on the fix anyway.
I will fix ClassPath soon too. Checking in manifest.mf; /shared/data/ccvs/repository/contrib/omnidebugger/manifest.mf,v <-- manifest.mf new revision: 1.4; previous revision: 1.3 done Checking in src/org/netbeans/modules/omnidebugger/Debug.java; /shared/data/ccvs/repository/contrib/omnidebugger/src/org/netbeans/modules/omnidebugger/Debug.java,v <-- Debug.java new revision: 1.5; previous revision: 1.4 done Checking in nbproject/project.xml; /shared/data/ccvs/repository/contrib/omnidebugger/nbproject/project.xml,v <-- project.xml new revision: 1.3; previous revision: 1.2 done
Created attachment 28837 [details] Proposed patch to ClassPath
Does this mean that there is not way to get class file reliably? Or is it enough to attach some "fake" listener to it and it starts behave reliably? (maybe, I should go with this to mailing list)
A workaround is to attach a dummy listener, yes. I rather used FileBuiltQuery since that was all I really needed to begin with.
CP fix: committed * Up-To-Date 1.34 java/api/src/org/netbeans/api/java/classpath/ClassPath.java committed * Up-To-Date 1.8 java/api/test/unit/src/org/netbeans/api/java/classpath/ClassPathTest.java
The patch is OK. Thanks.
In NB 5.0, if you create a new NBM project and ask for its COMPILE or EXECUTE classpath, getRoots() will not include build/classes (since it does not exist). After compiling, it still will not include build/classes - unless you add and remove a dummy PropertyChangeListener to the ClassPath first.