Bruce Chapman found the new "apt" tool that we all get with Java 5. The tool allows you to run your own code inside the compiler, so you can examine the source being compiled, generate other code, and more. This comes in really handy when you are using annotations, and already people are looking at adding Design by Contract annotations that apt enforces.

Apt internally runs javac code, so it can't actually be deprecated. But it will be interesting to see the innovation that comes out of being able to plug-in to this layer!

Read: Deprecate JAVAC

After reading the "apt" api it seems that you cannot run annotation processors after javac. :( Am I wrong here?

Bill

After reading the "apt" api it seems that you cannot run annotation processors after javac. :( Am I wrong here?Bill

Mostly true. If a side effect of annotation processing is the generation of new source artifacts that contain annotations, then that artifact will be processed and compiled in a new round after the original compile. This will continue until no new source artifacts are generated.

But for any single artifact the order is generally:

1. parse - syntax errors emitted here, and processing stops on errors
2. call annotation processors - can do semantic validation driven by annotations, generate additional info/warning/errors or new source/text/binary artifacts
3. compile

Bill, I have a fair amount of experience working w/ apt... if you tell me more specifically the use case you feel is blocked, maybe I can suggest something.

-- Kyle

After reading the "apt" api it seems that you cannot run annotation processors after javac. :( Am I wrong here?Bill

Mostly true. If a side effect of annotation processing is the generation of new source artifacts that contain annotations, then that artifact will be processed and compiled in a new round after the original compile. This will continue until no new source artifacts are generated.But for any single artifact the order is generally:1. parse - syntax errors emitted here, and processing stops on errors2. call annotation processors - can do semantic validation driven by annotations, generate additional info/warning/errors or new source/text/binary artifacts3. compileBill, I have a fair amount of experience working w/ apt... if you tell me more specifically the use case you feel is blocked, maybe I can suggest something.-- Kyle

I want to use it for JBoss AOP. Basically, the first pass will load annotations for interceptor bindings, second phase would happen after Javac so that the AOP framework can massage/aspectize the bytecode. Basically, I'm not doing any java source code generation, but rather transformation.

I'm looking for a nice way to implement our AOP precompiler.

Bill

I want to use it for JBoss AOP. Basically, the first pass will load annotations for interceptor bindings, second phase would happen after Javac so that the AOP framework can massage/aspectize the bytecode. Basically, I'm not doing any java source code generation, but rather transformation.I'm looking for a nice way to implement our AOP precompiler.Bill

Yeah, I'm not sure APT can fully help you here. Its processing model is oriented towards the tasks I describe in my previous post (semantic validation of annotations and generation of new artifacts), not to post-compilation mods to class files. You could use it to process/validate the annotations and then drop some secondary file that is used as input to a post-apt aspect tool.

The APT classes also have invocation entry points so it can be called from other java code (similar to how javac can be invoked in-process); so another possibility is for your precompiler to just invoke apt (the classes, not the executable) as part of its larger processing. I don't think these entry points are documented, though.

Couldn't this be used to implement aspect oriented developement?

So this is the place to add my long wished for properties support?

@get String name;
public void setName(name) {this.name = name;}

@get @set String name;

@get @set @PropChange String name;

@get @set @PropChange @VetoChange String name;

Complete with compiler error if the class which contains a @PropChange does not have a "firePropetyChangedEvent" method?

There are some serious misunderstandings about what apt is actually useful for. As the documentation states, apt only provides a "source-based, read-only view of program structure." You use apt to generate new code, not modify existing code. This means that apt is mostly useless for a large set of tools.

IMHO, Sun needs to extends apt to make the AST they provide writable. That would make it very useful for all sorts of tools (including the aforementioned JBoss AOP).

God bless,
-Toby Reyelts

IMHO, Sun needs to extends apt to make the AST they provide writable.

Agreed, but there are prerequisites that need fixing. Javac's AST API isn't publicized, and merely to view it a person must contaminate himself by accepting Sun's community license.

On java.net I read your suggestion that "For platforms like Java and .NET, we'll probably start to see ASTs that are language agnostic, but virtual machine specific." That's a fascinating prediction of yours. You seem to be alluding to AST reconstruction from bytecode, which is what decompilers do. Is even the best decompiler (Jad?) reliable at this, especially if the classfile was optimized or compiled from a non-Java language?

Anyway, I agree with you that a publicly mutable AST would be awesome.

It must be possible to use eclipse compiler for this stuff
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/