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: | NPE from usages finder | ||
---|---|---|---|
Product: | java | Reporter: | _ tboudreau <tboudreau> |
Component: | Unsupported | Assignee: | issues@java <issues> |
Status: | RESOLVED INVALID | ||
Severity: | blocker | CC: | jchalupa |
Priority: | P3 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | patch for java\navigation that illustrates the problem |
Description
_ tboudreau
2005-09-20 09:06:24 UTC
100% reliable way to reproduce: Check out jnn sources: cvs co -d:pserver:USER@cvs.dev.java.net:/cvs jnn Calling UsagesFinder to find usages of the method show() in that class will always produce an NPE - i.e. NamedElement showMethod = //find the element UsageFinder uf = new UsageFinder (showMethod); uf.getUsers (new Resource[] { showMethod.getResource() }); will throw it. UsageFinder is not API class, you use it at your own risk. You should not use it at all. Anyway - it looks like you created instance of UsageFinder for Callable Feature with incorrect constructor. Use constructor with 4 parameters for Callable Features. Created attachment 24963 [details]
patch for java\navigation that illustrates the problem
I know it's use at my own risk, I just wasn't sure if it was a real problem you guys didn't know about. I'll try the other constructor. What I'd really like to figure out is why, if I find all the locations in the document where "getFoo" occurs, why calling getElementAtOffset for some cases returns to me a giant StatementBlock, or the entire class, or other weirdness - finding all the string occurances of what I want to look for, and then just checking if each one is a VariableAccess/MethodInvocation of my method is way faster than UsagesFinder anyway. Tim's last question seems to be about the java model support, not about java/navigation. Reading all the comments, I'm not sure this should be tracked as a defect at all. If the javacore guys are satisfied that the code path that causes the NPE will never be triggered in a "normal" run of NetBeans, then, sure, close it. My code isn't passing any nulls, so it does look like something is broken somewhere in UsagesFinder. Up to you guys. This exception cannot be triggered in a "normal" run of NetBeans. Reorganization of java component |