"BaseInjector" holds a type-safe linked list of "BaseInjector" types. Recall the class that does the bytecode engineering and introduces method calls either before or after the annotated method. The code that's introduced during bytecode engineering is based on the "BaseInjector" class and is resolved at runtime via the Spring framework. So from a developer's perspective to introduce code that's executed either before a business method or after a business method, he or she would:

• Create a class (or classes) that extend "BaseInjector" and implement the execute() method.
• Annotate the business methods you want instrumented specifying two parameters, the bean lookup key that Spring will use to build your interceptor and the 'pre' or 'post' specification that tells the bytecode engineering code where to tack this interceptor on.
• Configure your Spring file.
• Run the application with the appropriate command-line switches that properly run the agent prior to main being called and installs the class-file transformer.

For completeness, here's a snippet of the Spring configuration file that wires up the interceptor. Please note that it's possible to chain together interceptors; Spring will accommodate this quite nicely via its ability to reference other beans under its control and apply them in setters or constructor arguments. Please consult Spring's documentation for more information on this. In this context, the annotation would specify the "nullInjector" as the processBean attribute and either "pre" or "post" for the insertionPoint attribute that designates where the developer intends to have the code executed.

<!-- Null Injector -->
  <bean id="nullInjector" class="injectors.NullInjector"  singleton="false">
  <constructor-arg><ref bean="interestingInjector"/></constructor-arg>
</bean>

At runtime, the injected code looks up the interceptor logic via Spring based on the value of the "processBean" attribute specified on the annotation being processed. Once retrieved, the injected code calls the "execute()" method on the bean that in turn executes whatever code happens to be in the "execute()" method. This pattern is fairly common in application server environments whereby the container must execute a series of interceptors either before or after the target business method. For instance, a J2EE container may do this on an EJB call to facilitate security, logging, statistics, and the like before actually executing the target method on the bean itself.

Summary, Conclusion, and the Ubiquitous Product Disclaimer
There are some really notable inclusions in the latest release of Java. At the very minimum, developers should embrace generics as a way of making code safer and more readable. Generics also support a tighter contract between caller and service that's generally always a good thing. The annotation framework shows great promise for tool and framework writers. EJB 3.0 threatens to lean heavily on annotations and I suspect this may cause the pendulum of "xml configuration hell" to swing the other way. Developers will be able to introduce metadata closer to the source, which will eliminate the proliferation of deployment and runtime files that seem to be on the increase. Sun also seems to be inventing ways to open the JVM up a little to framework authors and tool builders; as evidence we've looked at some of the new hooks available to us for class loading and on-the-fly class manipulation. I encourage developers to poke around the "java.lang.annotations," the "java.lang.instrument," and the "java.lang.management" packages. It's this "poking around" that inspired some of the goodies in this article and the tiny framework that subsequently developed.

I also encourage you to download, look at, hack, and run the source code available with this article. I've included pertinent snips of code, but the gist of this framework is best realized by looking at the entire landscape.

Whoops, I almost forgot the product disclaimer. I wanted to make sure that I stated that this framework is a conceptual work and that I do not represent it as a full-blown aspect-oriented system. I feel the concepts here are viable and could be developed into a very rich, robust system but as set forth here are primarily intended as a backdrop to the new capabilities of Java.

Resources

• http://java.sun.com/j2se/1.5.0/docs/api/
• www.onjava.com/pub/a/onjava/2004/04/21/declarative.html
• http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html
• www.springframework.org/docs/reference/index.html

• Source Code (zip file format)