问题
I am writing some tools for our build system to enforce some strict calling conventions on methods belonging to classes containing certain annotations.
I'm using the Compiler Tree API...
What i'm wondering is when traversing the 'tree', how can you tell the type of class/interface for a MethodInvocation.
I'm subclassing TreePathScanner with :
@Override
public Object visitMethodInvocation(MethodInvocationTree node, Trees trees) {
}
I'm hoping theres a way to tell the type of the class(or interface) that you're trying to invoke the method on. Am I going about this the wrong way? Thanks for any ideas...
回答1:
There are a couple of issues here. You can either be interested in
knowing the Java type of the method invocation receiver or just
knowing the class on the method is invoked. Java information is more
informative as it gives you generic types as well, e.g. List<String>
while Elements would only provide you with the class, e.g. List<E>
.
Getting the Element
To get the Element of the class the method is invoked on, you can do the following:
MethodInvocationTree node = ...;
Element method =
TreeInfo.symbol((JCTree)node.getMethodSelect());
TypeElement invokedClass = (TypeElement)method.getEnclosingElement();
Corner cases:
1.
invokedClass might be a superclass of the receiver type. So running
the snippet on new ArrayList<String>.equals(null)
would return
AbstractList
rather than ArrayList
, since equals() is implemented
in AbstractList
not ArrayList
.
2.
When handling array invocations, e.g. new int[].clone()
, you would
get TypeElement
of class Array
.
Getting the actual type
To get the type, there is no direct way for determining it what the
receiver type is. There is some complexity in handling method invocations
within inner classes where the receiver is not given explicitly
(e.g. unlike OuterClass.this.toString()
). Here is a sample implementation:
MethodInvocationTree node = ...;
TypeMirror receiver;
if (methodSel.getKind() == Tree.Kind.MEMBER_SELECT) {
ExpressionTree receiver = ((MemberSelectTree)methodSel).getExpression();
receiverType = ((JCTree)receiver).type;
} else if (methodSel.getKind() == Tree.Kind.IDENTIFIER) {
// need to resolve implicit this, which is described in
// JLS3 15.12.1 and 15.9.2
// A bit too much work that I don't want to work on now
// Look at source code of
// Attr.visitApply(JCMethodInvocation)
// resolveImplicitThis(DiagnosticPosition, Env, Type)
} else
throw new AssertionError("Unexpected type: " + methodSel.getKind());
Note:
The receiver
type needs to be TypeMirror
not DeclaredType
unfortunately. When calling new int[5].clone()
, receiver
would be
an ArrayType
of int[]
, which is more informative than the previous
method.
Getting it to run
Both of the previous methods require the compiler to resolve the type
information for the classes. In usual circumstances, the compiler
only resolve the types for method declarations but not the bodies.
Hence, the methods described earlier would return null
instead.
To have the compiler resolve the type information, you can do one of the following ways:
1.
Use AbstractTypeProcessor
class that just got added to the
compiler repository for JDK 7. Check out the work on JSR
308 and their compiler.
While the work is mainly on annotated types, it might be useful for.
The compiler allows you to use the provided class in a backward
compatible manner with Java 5.
This approach allows you to write processors that get invoked just like your current processors.
2.
Use JavacTask
instead and call JavacTask.analyze()
. Look at
the main method of this javac test to see how
to invoke your visitor on the classes.
This approach makes your processor look more like an analysis tool rather than a plug-in to the compiler, as you would need to invoke it directly rather than have it be a regular process.
来源:https://stackoverflow.com/questions/1066555/discover-the-class-of-a-methodinvocation-in-the-annotation-processor-for-java