Both front-end syntaxes will be supported moving forward, so developers will be able to pick their poison (AspectJ language, or AspectWerkz annotations / Java API).
One interesting point is that BEA is supporting the effort, and this is shown by the fact that the product will continue to live at Eclipse. It makes total sense, as now the platform can grow at a faster rate since they benefit from the work of the AspectJ team as well as the AspectWerkz team.
We talked to integral players from all sides and got the following quotes:
Gregor Kiczales, AOP Father
I think this is a great development for AOP technology and AOP users. From talking to a number of users and potential users of the technology I hear two common concerns -- a desire to see some sort of harmonization among the tool providers, and a clear commitment from major vendors to put resources behind supporting the technology. The new plans for AspectJ 5 do both.Adrian Colyer, AspectJ lead
Two major vendors are committed to supporting an open technology base.
What I hope will happen at this point is that the other big players using AOP in industry will see this move as beneficial to them. Because I think it clearly is.
A strong underlying platform benefits everyone, by allowing vendors and users to start shifting their focus to the real long term value - the aspects, the libraries of aspects, and the kinds of strategic opportunities that systematic use of aspects offers in platforms and applications.
AOP is really heating up now. There's this announcement, and it seems like there's a new book every couple of weeks lately. I'm more excited about it than ever.
Why did you decide to merge in this manner?Jonas and Alex, AspectWerkz leads
The roots of this merger go back a long way. Jonas and I first talked about some possible interactions between the two projects (such as enabling AspectWerkz to exploit the ajdoc and IDE capabilities that AspectJ offers, and AspectJ possibly benefiting from some of the AspectWerkz LTW smarts) at the AOSD conference in Lancaster in March of last year. It was obvious even then that we had very complementary strengths. The next significant event was probably the TSS conference in June 2004, where it became obvious to all the attendees that AOP was firmly on the radar. That's the event that kick-started the relationship between AspectJ and Spring, and where the realisation that some kind of integration / standardisation between the various AOP approaches was both
(a) possible, and (b) desirable. When you look at the subsequent development in AspectWerkz, you see their pointcut language getting closer and closer to that of AspectJ's. Over the summer we started a set of talks between the two projects about a possible merger, since its important to have not just the same syntax for common constructs (e.g. pointcut
expressions) but also the exact same semantics. It was when we managed to get some face-to-face time together at the OOPSLA conference in Vancouver last October though that we finally made significant progress. We got deep into some of the technical and project issues and realised a number of things collectively: (a) that this was going to work, (b) that the resulting design had some really exciting properties, which neither team could easily recreate working on their own, and (c) that the personalities clicked and we were able to work really well as a team.
What are the synergies between the two projects?
The strengths of the two projects are very complementary. AspectWerkz has excellent LTW support and Jonas & Alex have spent a lot of time making that really easy to configure and to integrate into J2EE environments. Of course, they also have the annotation-driven style of aspect specification and the ability to externalize aspect configuration. AspectJ has the richest pointcut language, a lot of supporting collateral (books, training, consultancy, etc.), and strong IDE support. With the release of AW 2.0, both have runtime performance that blows away the competition.
Looking forward, both projects had to address the big issue of Java 5 support (which is a lot more than just being able to match the execution of methods with some annotation), and each needed to press into the areas where the other was strong. We decided we could do better together than producing two competing implementations that would have been getting closer and closer with every release. From the progress we've already been making, I know that we were right.
How do you think the integration will happen? Are there challenges?
The first key thing to say is that we're not starting cold with this announcement. We've been collaborating for a few months now and had some excellent technical design sessions. Some great things fell out of those design meetings. For example, a way to do AspectWerkz annotation style development but preserve the AspectJ semantics, and my personal favourite, a way to define aspects in XML that has perfectly well-formed semantics.
We've been able to move at speed and a lot of the integration is already underway - we're well on the road towards the LTW enhancements and support for an annotation-style of development already for example. Some of the challenges we face are getting used to a new codebase (for Jonas and Alex), keeping AJDT moving forward so that it can support all the great new features (we'll add full support for the annotation style of development for example), and of course moving to a Java 5 foundation while we do all this. We have great news on that last front too, at time of writing AspectJ 5 has been successfully moved onto the Eclipse Java 5 compiler, and 1401/1427 tests are passing. I expect to have a developer build posted with this support in it next week.
How do you hope this will change the AOP landscape?
What I'm most hoping for is that the merger helps to accelerate the adoption of AOP in the enterprise. I think its a much stronger statement to say that 2 of the leading J2EE vendors agree on their approach to AOP and are contributing to the same open source project than it is to have a situation where each vendor is backing their own favourite horse. When companies see that large established vendors like IBM and BEA are taking AOP increasingly seriously and are working together, it should give them increased confidence to look into and start using AOP in their own projects. I think that's good for the whole AOP field, not just for AspectJ 5.
What are the short term goals?
Our immediate goal is to put out an AspectJ 5 release with Java 5 support, enhanced load-time weaving, and support for an annotation-driven development style. We want to release a version of AJDT with full support for these new features at the same time.
What are the long term goals?
Over the course of this year, we want to get AspectJ 5 to the point where any existing AspectWerkz user can easily migrate (AspectWerkz 2.0 will continue to be supported btw - it's not going to drop off the planet) to the new platform. There are plenty of things to be done - bringing across more of the AspectWerkz features into the new codebase, developing and extending the aspect library that will ship with AspectJ 5, extending AJDT to deepen its integration with the Java tools in Eclipse and to support things like aspect-aware refactorings, the list goes on. We want to continue to move AOP into the mainstream, and are committed to building the tools and technology needed to make that happen.
So, are you excited about this all?
There are a thousand things to be excited about. This is an amazing time to be involved in AOP full-stop. I'm doing some of the most interesting technical work of my career (no, scrap that, it's *the* most interesting technical work of my career). As a team we're doing things that nobody has ever done before, and both the quality of the ideas and the rate of progress that are coming out of the collaboration with Jonas and Alex are going to help us move forwards at great pace in 2005.
Why did you decide to merge in this manner?Read the announcement: AspectJ and AspectWerkz to join forces.
As Adrian said, we had been discussing for a collaboration for a while. There was mainly two options. One was to define a set of joint specifications to build the runtimes on it. This specification would have to handle a wide range of things like pointcut language, programming model exposed to the user, binary format of the aspect and so on. Thought it may appear as a good option, I am not convinced by the fact that it would have been beneficial to the users.
The other option was to agree on common goals and objectives, see if we would all enjoy working together, and work as one single team on the same objectives and the same implementation. This brings much more value to the users, and brings much more confidence in the implementation.
In the last version of AspectWerkz we had designed our architecture to reach the concept of an extensible AOP container, where it is possible to run AspectWerkz aspects, but also other kind of aspects, like AOP-alliance interceptors (thus Spring AOP aspects) and a very limited subset of AspectJ aspects. This architecture was a way for us to validate that this kind of runtime was possible and valuable though challenging. Bringing this concept further up to this merge is its best conclusion.
What are the synergies between the two projects?
For a while, AspectWerkz was following the AspectJ pointcut language and the AspectJ concepts. We decided to do so, first because it is obvious that all the Java AOP ommunity is thinking that way, sharing the same terms and concepts, and second because it ensures the AspectWerkz users investment to be protected when they decide to use AspectJ when they are ready to write aspects in a dedicated language.
We had observed that several of our users where also AspectJ users, and my guess is that the community was spending more time in figuring which implementation was best at fitting their needs rather than actually using the technology. This move will bring them to the next step.
In AspectJ 5 we will bring most of the features that were at the heart of AspectWerkz: plain java aspects defined with annotations, hability to refine the system using XML, load time weaving and J2EE integration schemes etc. This won't be a copy paste of some source code. This will be re-engineered by the whole team, and it will end up in a much consistent implementation that adresses the same use cases. This is already my feeling.
What does this mean for AspectWerkz users?
Though this question is largely answered in the document we have prepared to announce thsi merge, it is important to emphasys that AspectWerkz users will be able to switch to AspectJ 5 this year, with a minimal effort. We will work at providing hands on material and emphasys on the key differences further on, and if there is a need for it, it will be possible that we develop an automated migration script.
The differences between the AspectWerkz styled aspects and the AspectJ
5 annotation defined aspects are limited, and already clearly identified.
In a more long term perspective, AspectWerkz users will (and are already) part of the biggest AOP user community, and can speed up by reading resources on AspectJ with more interest. They will use the probably most mature and complete AOP implementation available in Java, backed by a common set of articles, conference coverage, books, tools, etc. I think things could not happen in a best way for them.
In the meantime, we will fully support AspectWerkz, provide support on the mailing list, and maintain the 2.0 release. We have user that are still using AspectWerkz 1.x and we are supporting it as well.
The merge also raises the question of what does this bring to non AspectJ and non AspectWerkz users. I think we have a lot to offer to them as well, once again by providing the best of both world, and ensuring higher quality and evolution pace by working together.
How do you think the integration will happen? Are there challenges?
We have been working on it since some time and some part of it are already implemented. There are challenges in the details like how to deal with aspect instantiation models in a consistent way accross the syntaxes, or how to deal with inter type declaration and mixins. We have plans for those.
Apart from the engineering challenges, there are human challenges, working all together on one implementation, with a bigger user base, targetting even higher quality and delivery objectives. I am confident in those one as well. Collaboration can only be beneficial.
How do you hope this will change the AOP landscape?
I hope we deliver a clear message through this merge. We are determined in bringing AOP further in a way that maximizes the value for the users, both existing users and future ones.
I am excited about the engineering challenges and human challenges that are at the heart of the marriage.