Community
Participate
Working Groups
I'm trying to store IJavaElements in a HashTable. I'm finding that some elements are throwing NPE while generating the hashCode because the LocalVariable object is initialized with a null parent. Exact reproduction of this case may be difficult
Looking at the code, I don't see how a local variable with a null parent can be created. How is the local variable obtained? (i.e what API is used?)
Ah that's fair. Perhaps you can help me out. I can reliably reproduce this on my workstation, but I don't know that I can reasonably, for instance, ship you the workspace, given that it's got copyrighted material. I have set a conditional breakpoint in LocalVariable's ctor that engages only when parent is null. I can do it again. The easy thing I can do is send you part of the stack trace. I'll hunt down a little more.
Yes, providing such a stack trace can help identifying the problem.
Jerome, here is some information. I suspect the nature of the anonymous class will be helpful. Stack trace: LocalVariable.<init>(JavaElement, String, int, int, int, int, String) line: 42 VariableBinding.getUnresolvedJavaElement() line: 222 VariableBinding.getJavaElement() line: 132 (The caller)JavaTypeFinder$1.resolveName(Name) line: 278 In VaribleBinding.getUnresolvedJavaElement, is where the null value comes from. It's the local variable's method. Method comes from (as you would know) declartingMethod.getJavaElement(). MethodBinding.getJavaElement calls MethodBinding.getUnresolvedJavaElement It calls (IType)getDeclaringClass.getJavaElement(). This returns null. FYI, the toString of the declaring class is: Anonymous type : (id=NoId) final class $Local$ extends java.util.TimerTask enclosing type : MyClass /* methods */ void <init>() void run() Does this help?
Unfortunately the line numbers don't match with my version (I assumed you were using one of the latest 3.4 build as indicated in the Version field). What is your Eclipse build number?
3.3.0. Build id: I20070625-1500
Thanks. I think this can happen only if the compilation unit is changed (or the working copy is discarded) after the binding was obtained.
Created attachment 85186 [details] Proposed fix and regression test
I think this might not be what's happening to me. You can help me verify this: Can you identify a breakpoint that would fire when the compilation unit is changed (or working copy discarded)? If you can do that, I can set it and test.
A org.eclipse.jdt.internal.core.CompilationUnit can be changed when the following methods are called: - makeConsistent(*) - reconcile(*) A working copy is discarded when org.eclipse.jdt.internal.core.CompilationUnit.discardWorkingCopy() is called.
> I think this might not be what's happening to me. Robert, do you have more information on your scenario ? Did you try the patch from comment 8 ? if so, does it fix your problem ?
Sorry for the delay. I haven't tried this, I don't really know how I can apply the patch and run it against my environment. If there is a build against which I can run this, I can try to verify it.
Fix and test released for 3.4M6. This fix will be in next week's integration build (it should be I20080219-0800). Please reopen this bug if you still have the problem with this build.
Verified for 3.4M6 using build I20080324-1300.
I have downloaded 3.4M6 and, set breakpoints and will let you know if it reoccurs. Thank you for your help.
