It is not permitted for an annotation processor to modify a Java source file, so a processor willing to add code to an existing class is left with only two solutions (if we exclude method instrumentation): Generating a superclass or generating a subclass.
Generating a superclass has the advantage that the constructors of the annotated class can be used directly. Let say that we have a annotation processor that is designed to help implement class composition, as described in Effective Java, item #16. Instead of writing the whole ForwardingSet class, an annotation processor could generate it automatically from this code fragment:
@Forwarding(ForwardingSet.class)
public class InstrumentedSet<E> extends ForwardingSet<E> {
InstrumentedSet(Set<E> s) {
super(new HashSet<>());
}
But generating a superclass is not always possible. For example let’s imagine an annotation processor that generates the JMX boilerplate necessary to export attributes. An existing class with such annotation could look something like this:
public class MyData {
@Attribute int counter;
}
In this case the processor for the @Attribute annotation will generate a JMX interface (Let’s call it MyDataMXBean) that declares the getcounter and setcounter methods, and a class extending MyData and implementing the JMX interface (let’s call it MyDataImpl).
The code generated would take care of the boring stuff, like synchronization and so on, which is certainly an improvement over writing and maintaining it. But the problem with subclasses is that we do not know the name of the class that was generated. Note that we have no other choice than to know the name of the superclass because we have to inherit from it. For subclasses it is better to let the processor choose the name, but now we need a way to be able to instantiate the generated class without knowing this name (in our example to register it in the MBean server).
The obvious way of doing this is to use a ServiceLoader. We can add a factory method in the MyData class to instantiate the generated class, something like this:
static MyData newInstance() {
return ServiceLoader.load(MyData.class).next();
}
But for this technique to work, we need to describe the service in the jar file. Using the method explained in a previous post does not help in this case, because we still do not know what will be the name of the generated class.
The version 0.2.30 of jarc provides a solution to this problem. This new version contains a new annotation, @Service, that can be used to annotate a generated class. A processor integrated in jarc will read this annotation at compile time, and automatically generates the service entry in the built jar file, as if an X-Jarc-Service attribute has been added to the manifest file. This works because this processor will be invoked after the @Attribute processor, and so knows the name of the class that has been generated. Here is for example the code fragment that the code generator would have generated for MyDataImpl:
@Service(MyData.class)
@MXBean
class MyDataImpl extends MyData implements MyDataMXBean {
Note that classes used as services require an empty constructor and that can be a problem if the class it extend does not have an empty constructor itself. The solution in this case is to define an additional factory class as the service.
First we define our factory as an abstract class:
abstract class Factory {
MyData newInstance(int init);
}
We adjust our factory method accordingly:
static MyData newInstance(int init) {
return ServiceLoader.load(Factory.class).next().newInstance(init);
}
The @Attribute processor must generate an additional class that extends the factory class and this is the class which is declared as a service:
@MXBean
class MyDataImpl extends MyData implements MyDataMXBean {
@Service(Factory.class)
static class FactoryImpl extends Factory {
MyDataImpl newInstance(int init) {
return new MyDataImpl(init);
}
}
MyDataImpl(init init) {
super(init);
}