Abstract classes annotation processing

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Jul 8 11:47:56 PDT 2013


On 07/08/2013 10:17 PM, Aleksey Shipilev wrote:
> Hi Julien,
> 
> On 07/08/2013 09:47 PM, Julien Nicoulaud wrote:
>> It seems JMH's annotation processor does not look into super classes for
>> annotations. It would be great to support that, as it would allow to have
>> "pseudo-parameterized" tests, for example something like this:
>> https://gist.github.com/nicoulaj/5950889
> 
> Hm, the premise was to allow this behavior (I even remember building the
> integration tests for cases like these). I had drafted the quick
> integration tests for your issue, and it is a bug. Let me see if it is
> easily fixable.

It is not easily fixable, because we lack the way to walk the class
hierarchy down from the superclass. In fact, that *does* makes sense,
because you can compile the JAR with the base class annotated with @GMB,
and compile the subclass separately. Annotation processor has no
knowledge what it should look for in the subclasses. (Pessimistically,
it should walk every single class and see if any superclass has the
methods with the annotation in question).

N.B.: @Inherited would be useful with this, but it only works on class
annotations, not the method annotations.

The workaround I see right now is to make @GMB methods in each subclass,
and call super right away, e.g.:

 abstract class BaseBench {
    abstract protected int doWork();

    @GMB
    public int measure() {
       return doWork();
    }
 }

 class Case1Bench extends BaseBench {
    protected int doWork() {
       return 42;
    }

    @GMB
    public int measure() {
       return super.measure();
    }
 }

-Aleksey.



More information about the jmh-dev mailing list