How to figure out class of method parameter given a VariableElement?

Question

Background:
I have a class that extends AbstractElementVisitor6<String, VisitorContext>
In visitExecutable() I do something like this...
try {
    // processingMethod is a member variable of the visitor
    processingMethod = true; 
    MyAnnotation foo = e.getAnnotation(MyAnnotation.class);
    if (foo != null) {
        List<? extends VariableElement> parameters = e.getParameters();
        for (Element enclosee : parameters) {
            enclosee.accept(this, context);
        // do other stuff
        return null;
    return null;
} finally {
    processingMethod = false;
}I then end up in visitVariable(VariableElement ve, P). Which is good.
However, I have been running in circles for at least a day now in the javadoc, trying to figure out how to get from a VariableElement to knowing what the class of the parameter is. I have figured out a way (correct or not) of knowing if it's a primitive type...
ve.asType() instanceof PrimitiveType But I'm stuck on figuring out what the class of the thing is. The closest thing I can see is if I can somehow turn the VariableElement into a TypeElement, I can use getQualifiedName(), but I'm haven't found that, and I'm not sure if that's the right answer either.
Here's the pseudocode of visitVariable...
public String visitVariable(VariableElement e, VisitorContext context) {
    if(processingMethod) {
        // if it's a primitive type - OK
        //  do the right thing
        // else
        //   figure out what the class of e is   HELP!
        //   do the right thing  
        return null;
}In summary...
How do I get the class of a method parameter from a VariableElement?
Thanks

Answer 1

When would this not be possible? Intersections types. See [JLS 3rd 4.9|http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.9] Specifically
"It is not possible to write an intersection type directly as part of a program; no syntax supports this."
Also, I'm curious about the string representation in the first place. I assume there's not direct handout of class objects because we're in the compiler and can't assume that a type is a valid "thing" yet? e.g. it may not have been compiled yetCorrect.
I was just thinking about how to represent the information, when it occurred to me that I probably ought to just reuse type mirrors and/or elements. Would you recommend this strategy? This is an interesting area of writing annotation processors. In order to apply any (what we call) extra-lingustic constraints and generate error messages when someone breaks the rules, you normally need the elements and types in order to make assertions about types being correct etc. I normally do this in the data collection phase, and don't collect any data for uses that are erroneous. I haven't tried doing the error checking after the collection phase.
When you are generating the source code, (after all the data is collected) all you need is CharSequences (normally Strings). In fact extracting those from elements and types at the point that is writing the source file can make the code more complex than it needs to be, so I prefer to just have everything in Strings at this point. It makes the code that is generating code a little easier to understand. I often build an inner class to hold all the strings (in fields or in collections as appropriate) which I have collected from each annotated element, so there is some structure there.
Are there any examples or other advice out there for doing this that you can point to?There are a few examples. Check out the [hickory project on java.net|https://hickory.dev.java.net/] You might find some useful tools there to assist writing your processor (such as prisms ) and [writing you unit tests|https://hickory.dev.java.net/nonav/apidocs/index.html?net/java/dev/hickory/testing/Compilation.html] . Hickory's unit tests include several examples of annotation processors, [this one|https://hickory.dev.java.net/source/browse/hickory/trunk/code/test/net/java/dev/hickory/incremental/ServiceProviderProcessor.java?rev=22&view=markup] illustrates the points I am making, and there are also some in code samples in the javadoc, for example [the same thing again |https://hickory.dev.java.net/nonav/apidocs/index.html?net/java/dev/hickory/incremental/StateSaver.html].
Bruce