The future of APT
Hi,
This message is mostly directly to Darcy (head of JSR 269). I was wondering what Sun's plans are for the future after JSR 269? I was very disappointed to find out that Mustang's processor is almost as limited as Tiger's was, allowing the implementation of very simple annotations such as @Override.
I am looking for the following features:
1) Ability to inject code (at compile-time) into a method based upon the annotation attached to it (useful for design by contract).
2) Ability to read the contents of a method *body*, not just method declaration (this relates to #1).
3) Access to a mutable AST or a very easy way to copy the read-only AST from one processing phase into another, and modifying its contents slightly in th process (i.e. adding or removing lines).
Maybe you know some tricks on how to achieve the above without any changes to JSR 269. If so, please let me know.
Thanks,
Gili
[957 byte] By [
cowwoca] at [2007-10-2 20:04:59]
Greetings.
Neither apt nor JSR 269 are designed to primarily to be used for AOP-like purposes so there are no mutable source files or mutable ASTs, etc.
However, with the current APIs, you can use something like the Decorator pattern from the patterns books to achieve much of the effect you want by having the code being operated upon makes reference to to-be-generated types. For example
// Initial source code
public class Starter {
@write(code="int i = 0")
public void something() {}
Starter factory() {
return new StarterImpl();
}
}
where the annotation processor generates
class StarterImpl {
public StarterImp(){}
public void something() {
int i = 0;
}
}
(Variants of this would include having Starter and StarterImpl implement a common interface and having a factory which returned the interface type; a Starter class object could directly wrap an instance of StarterImpl and delegate the method calls, etc.)
A second way is to generate the *superclass* of the Starter type. This technique is used by the rapt project, https://rapt.dev.java.net/, to implement mixins. For example,
// Initial source code
@write(name = "something", code="int i = 0")
public class Child extends Parent{}
with generated code
class Parent {
public void something() {
int i = 0;
}
}
One limitation of these approaches is that the code being processed has to be designed to be processed in this way.
JSR 269 will not include an AST model. However, Sun's JDK has added a Sun-specific, but supported, com.sun.source API modeling trees.
> Darcy,
>
> Can you please provide sample code for the first
> annotation processor? Specifically, I don't see how
> the processor injects "int i=0" into method
> something() if something() already has some sort of
> body.
The processor would not inject code into the existing body of the parent class; it would write that code (and everything else) into the child class which is entirely generated by the processor.
> How does JSR 269 represent the method body (it
> doesn't as far as I can see)?
Correct; JSR 269 itself does not include any representation of a method body.
-Joe
