JDK-6400041 : javax.lang.model.element.TypeElement.getKind() throws CompletionFailure
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 6
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2006-03-17
  • Updated: 2012-10-01
Related Reports
Duplicate :  
Relates :  
Description
It seems that since Mustang b75 the method javax.lang.model.element.TypeElement.getKind() throws unexpected exception for nonexistent type. Please see example below:

===
import javax.annotation.processing.AbstractProcessor;
import javax.annotation.processing.RoundEnvironment;
import javax.annotation.processing.SupportedAnnotationTypes;
import javax.lang.model.element.TypeElement;
import java.util.Set;

@SupportedAnnotationTypes("*")
public class Test extends AbstractProcessor {
     public boolean process(Set<? extends TypeElement> tes,
        RoundEnvironment renv) {
         System.out.println("kind: " + processingEnv.getElementUtils().
        getTypeElement("nOneXisTenT").getKind());
         return true;
     }
}
===
---------
F:\projects\jck>Z:\lnk\re\jdk\6.0\latest\binaries\windows-i586\bin\javac.exe -cp classes -processor
Test src/Test.java


An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for nOneXisTenT not found

Reproduced on jdk6 b75, windows xp, intel i586
---------

It seems this behavior contradicts to spec that says
====
TypeElement getTypeElement(String name)
...
     Returns:
         the named type element, or null if it cannot be found
===

Comments
SUGGESTED FIX If we create error symbols for completion errors, perhaps we could save them all in a cache until they have been reported, either by Resolve.access or at strategic points.
07-12-2006

SUGGESTED FIX I may have an idea to solve this problem. The reason why we throw completion errors is that we do not know where to report (of if to report) errors during type checking. I think we should move away from completion errors and try to find alternative ways to report missing symbols. This can be achieved if we stop throwing completion errors in the class reader (and source completers). Instead we should return a symbol that is marked an error. It should be possible to report this error through the method Resolve.access. There are some situations where this is not enough (overload resolution). In this case, we should log errors somewhere in the context and flush them on strategic places.
02-11-2006

EVALUATION Need to catch and handle CompletionFailure
15-08-2006