Bug 214002 - [dom] NPE in MethodBinding.getParameterAnnotations()
Summary: [dom] NPE in MethodBinding.getParameterAnnotations()
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M5   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-28 19:34 EST by Walter Harley CLA
Modified: 2008-04-09 20:06 EDT (History)
1 user (show)

See Also:


Attachments
Test case (1.77 KB, patch)
2007-12-28 19:39 EST, Walter Harley CLA
no flags Details | Diff
Proposed fix (1.07 KB, patch)
2007-12-28 19:59 EST, Walter Harley CLA
no flags Details | Diff
New proposed patch (8.55 KB, patch)
2007-12-31 06:13 EST, Frederic Fusier CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Walter Harley CLA 2007-12-28 19:34:36 EST
If some, but not all, of a method's parameters are annotated, then calling MethodBinding.getParameterAnnotations() on the non-annotated parameter will NPE.  The problem is that the bindingAnnotations array contains nulls, rather than empty arrays, for the non-annotated parameters.
Comment 1 Walter Harley CLA 2007-12-28 19:39:22 EST
Created attachment 85918 [details]
Test case

Attached test case demonstrates the NPE
Comment 2 Walter Harley CLA 2007-12-28 19:59:44 EST
Created attachment 85920 [details]
Proposed fix

If the nulls are intentional, here's a patch that copes with them.  But perhaps we instead should be filling in the bindings array with empty subarrays?
Comment 3 Frederic Fusier CLA 2007-12-31 06:13:27 EST
Created attachment 85949 [details]
New proposed patch

The initial intention was to fill the array with empty arrays when the parameter has no annotations (see MethodBinding.getParameterAnnotations()). But I missed the path when the parameter annotations are created while binding arguments in AbstractMethodDeclaration.bindArguments()...

Thanks Walter to have pointing this out and for the helpful test case :-)
Comment 4 Frederic Fusier CLA 2007-12-31 08:33:14 EST
Released for 3.4M4 in HEAD stream.
Comment 5 Frederic Fusier CLA 2007-12-31 08:37:31 EST
Of course, previous comment should read:
Released for 3.4M5 in HEAD stream.
Comment 6 Walter Harley CLA 2008-01-02 14:03:40 EST
Thanks very much, Frederic!  That seems to fix the problem.
Comment 7 Maxime Daniel CLA 2008-02-05 04:49:08 EST
Verified for 34M5 using I20080204-0010 build.
Comment 8 Kevin CLA 2008-03-26 13:23:00 EDT
I seem to get a NullPointerException in 3.4M5 from IMethodBinding.getParameterAnnotations() when requesting parameter annotations for a method where some, but not all, parameters are annotated.  It doesn't matter whether the parameter I request annotations for is annotated or not.  I'm a bit confused because the notes suggest this bug was fixed in M5, so I wonder whether this is a different problem.

The exception comes from jdt.core.dom.MethodBinding:

java.lang.NullPointerException
	at org.eclipse.jdt.core.dom.MethodBinding.getParameterAnnotations(MethodBinding.java:150)

The problem seems to be that jdt.internal.compiler.loopup.MethodBinding.getParameterAnnotations() skips over arguments with a null annotation array, which seems to be the case for parameters with no annotations:

for (int i = 0; i < length; i++) {
    Argument argument = methodDecl.arguments[i];
    if (argument.annotations != null) {
        ASTNode.resolveAnnotations(methodDecl.scope, argument.annotations, argument.binding);
        allParameterAnnotations[i] = argument.binding.getAnnotations();
    }
}

A fix might be to add an else branch to the above code that initializes allParameterAnnotations[i] to an empty array.  

In my example, the IMethodBinding was acquired from a method call site.  The call site resides in a different source file than the method declaration (not sure if that matters).  Can you reproduce this problem?  
Comment 9 Walter Harley CLA 2008-03-26 14:13:59 EDT
Hi, Kevin.  The test case that was created as part of this bug report is still passing, so it sounds like you may have a closely related but not identical bug.

Can you please open a new bug, and reference this bug number in the new one?  It would also be very helpful to post a test case, or at least a specific repro case, in that bug report, since it sounds like the difference may be subtle.  Thanks!

You might also just want to check whether the problem shows up in the latest I-builds (or 3.4M6, which should be available this Friday), as some more work has been done in this area since M5.
Comment 10 Kevin CLA 2008-04-09 16:02:35 EDT
Walter,

I checked with M6 and filed a new bug, #226357.  Hopefully you can reproduce the problem.  This also seems to be different from #214647.

Thanks,

Kevin
Comment 11 Walter Harley CLA 2008-04-09 20:06:49 EDT
Bugzilla tip: if you put the word 'bug' before a bug number, Bugzilla will automatically create a link.  Like this one to Bug 226357, and this one to Bug 214647.