Community
Participate
Working Groups
1. Project configured for external annotations for the requiredPlugins container and a dependency on org.eclipse.osgi 2. Open class file editor for interface "org.osgi.framework.Bundle" 3. Select the return type String of method getSymbolicName() 4. Invoke "Annotate" (Ctrl-1) => NPE is thrown by ExternalNullAnnotationChangeProposals.TypeRenderer Factors contributing to the problem: - interface Bundle has an annotation @ProviderType which is nowhere to find. The annotation has retention CLASS, so not having it available as part of the dependencies/deployment feels wrong to begin with. - the missing type triggers AbortCompilation in the compiler - CompilationUnitResolver is able to provide an AST, but no bindings are resolved whatsoever, not even j.l.String (due to the abort). - ExternalNullAnnotationChangeProposals fails to check for missing bindings Of course the NPE must be avoided at the end of the chain (I'll file a bug for that shortly). I feel that a fatal compile error (on an error-free class file) should be reported to the user if we cannot conceal the problem. One issue to be investigated in JDT/Core: shouldn't the CompilationUnitResolver just ignore the missing type (at least in this position)? I mean, recording a problem is OK, but throwing AbortCompilation is not, IMHO. Perhaps we can tune this by extending IErrorHandlingPolicy and let CUR provide a policy that avoids AbortCompilation if possible (need to check the different reasons for throwing). See also bug 363858 for prior art regarding CUR and AbortCompilation.
(In reply to Stephan Herrmann from comment #0) > Of course the NPE must be avoided at the end of the chain (I'll file a bug > for that shortly). I feel that a fatal compile error (on an error-free class > file) should be reported to the user if we cannot conceal the problem. That's bug 466232. Another factor contributing to AbortCompilation: Bundle depends on another type, FrameworkWiring, which, too, has the unresolvable annotation. This triggers the fatal IProblem.IsClassPathCorrect. See also https://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08210.html
While preparing a test for bug 466232 I had to understand the sequence of events in all details: Assume two types (plus a missing type): //-- package pack.age; import pack.age.Missing; @Missing public class Class1 { } //-- package pack.age; import pack.age.Class1; import pack.age.Missing; public class Class2 { } //-- Now compile sources of Class2 against binary type Class1. Assume that Class1 was compiled while pack.age.Missing was available, but now when compiling Class2 it no longer is found. 1. Resolving "import pack.age.Class1" we load BinaryTypeBinding Class1 1.a During initialization of Class1 we see the annotation "pack.age.Missing" and create an UnresolvedReferenceBinding for it 2. Resolving "pack.age.Missing" we find the UnresolvedReferenceBinding from before and try to resolve it now. 2.a. NameEnvironment doesn't find pack.age.Missing 2.b. URB.resolve(..) reports the infamous isClassPathCorrect(..) 2.c. ProblemHandler doesn't have a referenceContext, hence it converts the problem into AbortCompilation 3. Bye, bye resolved bindings In the original, the annotation (ProviderType) is of course imported for a purpose, but no actual reference using that import is needed for nuking compilation. We might even avoid to AbortCompilation in the compiler proper, for this specific problem pattern - but not for 4.5.
Bulk move out of 4.8
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
