Recently I had to work on a project whose a big chunk of the code was implemented by another team. And we were not supposed to change that code. But we were still somehow supposed to change the exception handling and logging for a certain kinds of Java classes on both that codebase and our own custom code.
Since we are on a pretty bad economy, instead of spending time to update my resume I thought of using this as an opportunity to test and learn AspectJ. It was a long shot but I read about it in the past, but never had a strong need to use it until now and thought it was worth trying. The thing is, I was interested in it a while back but thought it would be just like other technologies, like Spring, Hibernate, JSF etc. Think about it, if you need to do real work and have only 2 or 3 days, can you do something with Spring + Hibernate + JSF from scratch if you never worked with it before? The learning curve for most of these things is just too high if you need quick results!
Man, I am glad I tried AspectJ. I know its inner workings use some arcane technology (bytecode manipulation isn't for the faint of hearth), but it was SO much easier than I expected to hook my custom exception handling logic in the existing code I felt it was almost too easy to be true! :P
Since I think other people may benefit from this mechanism let me share some basic but still useful information about it. In a nutshell AspectJ is an arcane technique to alter behavior of existing Java binaries. You can transparently inject logic into certain "point cuts", like when a certain method name is executed, or when classes from a certain package are loaded etc etc. Few cool examples of what you can do with that are:
- a custom global logging mechanism to existing classes from a certain package (e.g. my.company.*)
- custom exception handling mechanism for certain exception types
- method profiling, for performance monitoring and tuning
- reduce LOC and complexity on your new code using aspects to handle multiple functional concerns transparently, outside your business classes
There are 2 main ways of using AspectJ:
1. Static-weaving: You can use AspectJ's ajc compiler to alter existing class files (either .java or .class), injecting your custom aspects and pack all changed files into a new JAR file. Then you put the new JAR in your classpath instead of the old classes (in most cases it may also work to just put the JAR first in the JVM's CLASSPATH). The Eclipse team divides this method as Compile-Time Weaving, when ajc compiles *.java into *.class injecting the aspects, and Post-Compile Weaving, when ajc injects aspects into pre-compiled class files. The performance penalty here is 0, it will be the same thing if you recompiled the original classes with your aspect's logic in it.
2. Load-time weaving: This is where AspectJ's magic is more evident - your original classes and JARs are modified when they are loaded by the JVM! You do not have to replace any JARs, it will all be done dynamically. In most cases the performance overhead imposed by AspectJ to "weave" your aspects in the existing classes is negligible when loading the classes, but note that there will be no runtime overhead - once AspectJ injects your aspects it will not mess with that class again.
If I have to choose between one of the 3 methods described above I would try Load-Time Weaving (LTW) first, because I think in most cases the performance overhead during class load times (note it is "load times" and not "run time") should not be enough to overshadow the benefits of not having to bother updating JAR files every time the original class must be updated. If there is a significant performance hit due a broad scope of weaved classes then it is easy to move to one of the two static weaving methods described in item 1 above.
Ok, enough talk, how can we actually use it? Let me describe it with a very simple example that can serve as the basis for whatever else you want to do with AspectJ: (yeah, you guessed) a custom logging and performance monitoring mechanism!
# Dev env setup
1. Download and install AspectJ Development Tools (AJDT) for Eclipse. You can download it here.
2. Download my AspectJ examples project here.
3. Extract the AspectJ examples project somewhere in your development environment and import it in Eclipse.
# Project notes
1. "test.Test.java" is a simple test class. Their methods will be intercepted by AspectJ to transparently inject additional behavior without us having to change any code in Test.java.
2. Our two aspects LogAspect.aj and MethodProfilerAspect.aj are located in package "aspects".
3. Eclipse with AJDT show us what aspects affecting each method in class Test.java in the Cross References view (we can see it in the screenshot above, in the bottom right). Just select a method in the Java editor and it will list the aspects in that view. Or select an aspect method in LogAspect.aj and it will list the intercepted methods in that view. This is pretty useful to control scoping, just keep in mind that AJDT will only list methods in its own classpath, and it may be different (i.e. the aspects may catch more classes) when you deploy the aspect JAR in the app server.
Without any aspects, this is the output of test.Test.java:
Test.method1 Test.method2 Test.method3
Enabling just LogAspect.aj we then get this output:
[LogAspect] before public static void test.Test.main(java.lang.String[]) [LogAspect] param[0]='[Ljava.lang.String;@12ac982' [LogAspect] before public void test.Test.method1() Test.method1 [LogAspect] after public void test.Test.method1() [LogAspect] before public java.lang.Object test.Test.method2() Test.method2 [LogAspect] after public java.lang.Object test.Test.method2() [LogAspect] returned 'null' [LogAspect] before public java.lang.Object test.Test.method3(java.lang.String) [LogAspect] param[0]='InputValue' Test.method3 [LogAspect] after public java.lang.Object test.Test.method3(java.lang.String) [LogAspect] returned 'ReturnValue' [LogAspect] after public static void test.Test.main(java.lang.String[])
And finally, enabling just MethodProfilerAspect.aj we get this output:
[MethodProfilerAspect] entering public static void test.Test.main(java.lang.String[]) [MethodProfilerAspect] entering public void test.Test.method1() Test.method1 [MethodProfilerAspect] exiting public void test.Test.method1() in 31ms [MethodProfilerAspect] entering public java.lang.Object test.Test.method2() Test.method2 [MethodProfilerAspect] exiting public java.lang.Object test.Test.method2() in 62ms [MethodProfilerAspect] entering public java.lang.Object test.Test.method3(java.lang.String) Test.method3 [MethodProfilerAspect] exiting public java.lang.Object test.Test.method3(java.lang.String) in 16ms [MethodProfilerAspect] exiting public static void test.Test.main(java.lang.String[]) in 109ms
If you look at the aspects' source code you will see how little coding was required for that. But this is just the tip of the iceberg, there are many other cool things we can do with AspectJ, like dynamically change the return value of certain methods, catch, modify and re-throw Exceptions etc.
So this is pretty powerful... but "with power comes responsibility" - you must be careful and not depend on too many aspects, or your project could become a maintenance nightmare!
# Additional interesting articles about AspectJ
- Pointcuts and Advices: http://www.eclipse.org/aspectj/doc/next/adk15notebook/ataspectj-pcadvice.html
- Join Points and Pointcuts: http://www.eclipse.org/aspectj//doc/next/progguide/language-joinPoints.html
No comments:
Post a Comment