Question

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…

Answer 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.