Comment 1 Karen Butzke 2006-05-23 12:50:11 EDT

Created attachment 42281 [details]
Test case project

Comment 2 Kent Johnson 2006-05-23 14:31:09 EDT

Reduced testcase:

class X {
	@Ann(m=Object)
	private int foo;
	private NonExisting bar;
}
@interface Ann {
	String m();
}

Comment 3 Olivier Thomann 2006-05-23 14:50:58 EDT

Created attachment 42299 [details]
Proposed fix

Simple fix that reverts to a linear search if one of the field binding is null.

Comment 4 Kent Johnson 2006-05-23 14:55:13 EDT

Created attachment 42301 [details]
Patch to clean up field array

The problem is in the method SourceTypeBinding.fields().

It nulls out a field when it detects that its type cannot be resolved, but continues to resolve the other fields, which cause an Annotation type to be resolved. We end up in getField where the null'ed out field is detected.

The proposed patch uses a separate set to keep track of the failed fields and builds the new field array but skipping the failed ones.

Comment 5 Kent Johnson 2006-05-24 11:06:34 EDT

We should make a similar change to SourceTypeBinding.methods() so failed methods are not null'ed out immediately.

Comment 6 Philipe Mulet 2006-05-30 06:55:15 EDT

Problem comes from annotation resolution (looking for @Deprecated) which is reentering field resolution (while fields are being resolved) to resolve 'Object' reference. 

Here is a scenario with methods, which doesn't cause any NPE:
public class X {
	@Ann(m=Object())
	private void foo(){}
	private NonExisting bar(){}
}
@interface Ann {
    String m();
}

Comment 7 Philipe Mulet 2006-05-30 07:14:26 EDT

Previous case doesn't fail, since unresolved return type is not directly nulling out the entry in method array.
Here is another case which causes a NPE with methods:
public class X {
	@Ann(m=bar())
	private void foo(){}
	private NonExisting bar(NonExisting ne){}
}
@interface Ann {
    String m();
}

Comment 8 Philipe Mulet 2006-05-30 07:52:35 EDT

My fix is along the same line as Kent's proposed one, except using an array which makes the logic closer to original one (especially on method scenario).
Added AnnotationTest#test202-207

Comment 9 Philipe Mulet 2006-05-30 07:53:45 EDT

Created attachment 42942 [details]
Proposed patch

Comment 10 Philipe Mulet 2006-05-30 07:56:45 EDT

The scenario is rather rare, it arises through annotation resolution and in presence of unresolved types. This is why it is safer to queue this one for 3.2.1, as opposed to RC7 where we want to be really conservative.

Comment 11 Philipe Mulet 2006-05-30 09:35:37 EDT

Created attachment 42948 [details]
Better patch

Had forgotten to use resolvedMethod in methods() when finding collisions

Comment 12 Philipe Mulet 2006-05-31 14:45:04 EDT

Added AnnotationTest#test202-207.
Released fix for 3.2.1

Comment 13 Frederic Fusier 2006-06-12 05:25:49 EDT

Released for 3.2.1
Released for 3.3 M1 while merging TARGET_321 in HEAD

Comment 14 Olivier Thomann 2006-06-13 13:35:41 EDT

*** Bug 146858 has been marked as a duplicate of this bug. ***

Comment 15 Frederic Fusier 2006-08-08 06:50:47 EDT

Verified for 3.3 M1 using build I20060807-2000.

Comment 16 David Audel 2006-09-11 10:25:58 EDT

Verified for 3.2.1 using build M20060908-1655