Jonas is still standing when I meet him at the Öredev conference to discuss an interview. Even though a cold is doing its best to bring him to his knees. He still has a ‘roundthe-globe’ trip to Tokyo to do and the following sprint to reach JavaOne in Japan another one of those Swedes going places.
Jonas Bonér is the founder of AspectWerkz, an aspect oriented framework without the need for special compiler. It later joined forces with AspectJ, which could be described as the Father Christmas of aspect oriented programming in the Java world. He used to work for BEA in Sweden, but has recently joined Terracotta, San Francisco.
Jonas you’re a long term AOP advocate. When and how did you start with aspects and, perhaps most importantly, why?
I started using AspectJ back in 2001 and I was immediately very fascinated by the concepts of AOP, its power, beauty and ability to solve really hard problems in such an elegant way. I have always valued clean design and simplicity and in AOP I found a way of letting design and concepts map directly to actual code.
I started by using ‘policy enforcement aspects’, e.g. AspectJ’s declare error/warning, logging and tracing aspects, as part of the build process. After a while I gradually started to use it for more advanced things, such as security, transaction demarcation, persistence, caching, “unit of work”, design patterns etc. for better modularity, reusability, maintainability and simplicity.
Why did AspectWerkz and AspectJ merge?
The short answer is that the users needed a standard. But let me elaborate a little bit. During recent years the AOP landscape for Java has flourished. When a technology is new and immature it is usually a good thing to have many frameworks/products competing, since they can inspire and push each other and the technology even further, but when the technology matures it starts to become a problem. For example, the users might end up not knowing which framework, syntax and semantics to start using, since they do not know which ones will even be around a year later. If you see this happen a lot, like it did with AOP, then there is a need for standardization.
During 2004, AspectWerkz and AspectJ slowly converged, but the two projects were still focused on different areas and had complimentary strength. We had some discussions and both teams saw the need for standardization and felt that both projects as well as the user community would benefit from unifying the projects, roadmaps and teams instead of competing. So we decided on the merger that was announced in the beginning of 2005 and was completed with the release of AspectJ 5 at the end of last year.
So where do you think we’re heading for in the future, as far as AOP is concerned?
I am confident that AOP will play an important role in the future of enterprise application development. Many vendors are already starting to embrace AOP as an enabling technology for separation of concerns, transparency, simplicity etc. For example Terracotta DSO, JBoss EJB 3, TopLink, Spring etc.
These are all examples of vendors using AOP to layer infrastructure services on the user’s domain models in a transparent fashion. That is great, but I hope that it won’t stop with that, my wish is that users will see the value of using AOP in their application specific code, in order to achieve more modular design, code that is more easily written, understood, reused and maintained. In some ways AOP had a healthy backlash over the last year, which has removed most of the hype around it. It has matured, has a standard in AspectJ 5 and is ready for real-world deployments.
Tool wise it seems that we have several things in place in Eclipse/AspectJ/ AJDT to get a good grip on aspects. Examples: being able to see what code an aspect affects, diff engines to compare changes to an aspect etc. Do we have all we need?
The AJDT team has done a tremendous job and I think that we have already come a long way, even though more work can of course be done and needs to be done in this area. But while this is true for static views of the system, like AJDT is showing, there is almost no support for monitoring and introspecting the runtime view of the system, something that is getting more important now when the usage of dynamic AOP is becoming more widespread, which has the ability of redefining the behavior of the system at runtime. This is an area in which I hope that the academic community will contribute more in the future.
Can you see anything that needs to be fixed or added before we see more widespread adoption of AOP?
I think that the most important thing now is education trainings, books, articles etc. We need to try to reach beyond the group of “expert” developers. Another thing is a standard library. We need an ADK (Aspect Development Kit) in the same sense that Java has its JDK. I am involved in an attempt to gather and develop a set of library aspects for AspectJ 5, and we’ll see where that leads. Finally I hope to see more best-practices, patterns as well anti-patterns emerge.
Terracotta, the new company you work for, has a distributed cache product. What’s so cool about it?
It is completely transparent. Meaning that zero code changes are required to cluster an arbitrary J2EE application. Our only requirement is that you have to write a correct multi-threaded application. We then take that multi-threaded single VM application and a tiny bit of XML configuration to declaratively specify what should be shared, lock semantics etc., and turn it into a multithreaded multi-JVM application. These are the features I find most interesting:
* True transparency.
* Noserialization.We only send the actual changes to an object graph (the delta) as well as keep track of who is referencing who, so we can send these changes only to the nodes that need it, e.g. lazily.
* Object identity is preserved. We maintain Java’s “pass-by-reference” semantics, so regular object references work, which means that you can use your domain model the way you have designed it, as well as traditional OO design patterns etc. without a need to think about distribution, caching or clustering. • Coordination and memory manage-ment. We maintain the Java Memory Model transparently throughout the cluster, including distributed coordination, for example wait(), notify(), synchronized() etc., distributed garbage collection etc. We work as a virtual heap, meaning that you can for example run an application with 200G heap on a machine with 4G of RAM in which we then page in and out the heap on a demand basis.
How does it work?
We use AOP technologies to adapt the application at class load time. In this phase we extend the application in order to ensure that the semantics of Java are correctly maintained across the cluster, this includes object references, thread coordination, garbage collection etc. For example, we extend the semantics of a regular synchronized block, or actually maintain them across the cluster, by taking a global lock for the object instance that you are synchronizing on right before entering the block and releasing it right after exiting the block. You can declaratively define the exact semantics for the block, e.g. read, write, concurrent etc.
Another example is the invocation of notifyAll(). Here we turn this call into a cluster wide notification, which will open up for all nodes to contend for the lock.
The architecture is hub and spoke based, meaning that we have a central server which manages the clients, we use TCP/IP so the server just needs to be somewhere on the network. The client in this case is simply your regular application together with the Terracotta JAR. People always ask whether the server is not a single-point of failure, but we have a SAN-based solution to support fail-over in an active-passive manner. You can have an arbitrary number of (passive) servers waiting in line and upon failure the selected one will pick up right where the master server that has crashed left off.
Finally, as an active open source contributor, do you have anything up your sleeve for the future?
I have some ideas, but nothing I can talk about now. Stay tuned…
Something tells me that we will hear more from Jonas Bonér.
His cold? Well the trip actually made it go away. He made JavaOne with half an hour to spare. I guess it’s that Viking blood.
Originally published in JayView.
Tumblelight 