AspectJ and AspectWerkz Merge Forces

Home

News: AspectJ and AspectWerkz Merge Forces

  1. AspectJ and AspectWerkz Merge Forces (25 messages)

    The AspectJ and AspectWerkz development teams have teamed up to create a new force in AOP. AspectJ 5 will consist of a merging of both open source frameworks, and we will all benefit. The joint product will have the mature AspectJ backend, their strong UI tools, and ajdoc. AspectWerkz will bring a great weaver, and an alternative pure Java syntax to the mix.

    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.
    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.
    Adrian Colyer, AspectJ lead
    Why did you decide to merge in this manner?

    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.
    Jonas and Alex, AspectWerkz leads
    Why did you decide to merge in this manner?

    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.
    Read the announcement: AspectJ and AspectWerkz to join forces.

    Threaded Messages (25)

  2. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    I, for one, am excited.
  3. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    would the aspectj developers still choose to extend the language if there were starting their work from scratch? in reflection, was it a good design decision that they would still stand by?

    great to see such a movement within the java aop world. best of luck to all concerned, but i'll be staying on the java side with AW.
  4. Would we still extend the language?[ Go to top ]

    would the aspectj developers still choose to extend the language if there were starting their work from scratch? in reflection, was it a good design decision that they would still stand by?

    Absolutely, yes. I firmly and passionately believe that when you start treating aspects as first class units of modularity in your application, and you use aspects as a core part of your application design - both in the large and in the small, then you really want them to be first class constructs in your programming language. There's also a bunch of things that you can do with a language (and associated compiler) that you just can't do solely with annotations - but that's a secondary point to me.

    I accept though that there are a whole set of people for whom using a new language is just a bridge too far - especially when just starting out in the AOP world. The really great thing about this merger is that you get a set of annotations, AspectWerkz style, that allow you to keep on using your Java compiler, but you also get absolutely consistent semantics and implementation with the "code style" of AspectJ development. This means that when or if you decide you want to try out the code style everything you've learnt just keeps on working and you can incrementally change your code base without going through a big bang. If you decide never to try the code style, that's fine too - you can still take advantage of tools like AJDT and ajdoc.
  5. Extending the language[ Go to top ]

    would the aspectj developers still choose to extend the language if there were starting their work from scratch? in reflection, was it a good design decision that they would still stand by?

    Great question. Another way to look at it is: are our users better served by a more concise syntax that extends the Java language, or by a less intrusive one that uses annotations or XML for aspects and pointcuts. There is a large number of tradeoffs, ranging from the benefits of having static checking for pointcuts, to having advice and pointcuts visually discernible in the IDEs structure views. On the flipside, extending the Java language means breaking the JLS, which means that all tools that rely on parsing plain Java need extending to support AspectJ.

    The merge, and move to support the @AspectJ syntax, will offer the same core AOP semantics in both an extended Java syntax, and a non-extended annotation-based syntax. So our combined user bases will have a choice of which syntax to use. Anders Hejlsberg recently called your choice of a language a lifestyle choice. He was really talking about your choice of .NET CLR syntax, and now our users will be able to make the same choice with AspectJ syntax. With AspectJ we have always stood by our opinion that extending the language is the better approach in long term. But after the dust settles we should finally start seeing the users' answer to your question!

    I just wrote a developerWorks article that contrasts AspectJ, AspectWerkz, JBoss AOP, and Spring AOP, and focuses on a discussion of the tradeoffs of extending the language. It'll be up within two weeks.
  6. WOW[ Go to top ]

    That is a real great news...

    We have been using AspectJ in our product and we were considering using AspectWerkz for our next version (run time weaving being one of our main conern)

    Will use that new product so.

    Good luck with the merge work et bon courage!
  7. Great!
    I hope that will be great example for miriads of other projects: people unite efforts!
  8. Forking seems to be more common than merging in the OSS world. This is great news. I wish you good luck.
  9. Great move! Prefer DSL![ Go to top ]

    This is a really great move! Congrats for all who made this happen! IMO, this should be taken as an example in the Open Source world... Candidates are:
    - JBoss - JOnAS - Geronimo (he he he :-))
    - LPortal - exoPlatform (Portal)
    - All those Java, J2EE CMS (Content Management System), LMS (Learning Management System), LCS (Learning Content System)
    - etc. etc. you name it!

    Now in matters of the language... I myself prefer to have a "domain" specific language (DSL) and compiler just like AspectJ. You have a lot more advantages using DSL, the most important part: you talk with the same *vocabularies* within your domain with other people! Can you imagine to talk about aspects without knowing what aspects really are? Thanks to AspectJ we all know what is the meaning of aspects... :-)

    Cheers,
    Lofi.
    EJOSA and OpenUSS.
  10. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    This is excellent news. Congratulations to all concerned for putting their user communities and the desire to create the best possible technology first. And, it's great to see BEA and IBM being supportive of this effort, as they must have been.

    AOSD should be very interesting this March. I look forward to further work with Adrian, Jonas and Alex to integrate Spring more closely with the new AspectJ.
  11. One of the most Look-Ahead mergers.
  12. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    This is great news! Both AspectJ and AspectWerkz are great products. I'm looking forward to working on closer integration betwen AJ, AW and Spring.

    Rob
  13. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    Great work guys!! Looking forward to seeing the strengths of both technologies combined!
  14. Where are Sun and JCP?[ Go to top ]

    I am concerned that this wonderful initiative has not been channeled though JCP. Both BEA and IBM have enough power to submit it, the syntax is already pretty mature and agreed upon, etc. Maybe a JSR is in the works already? Conversely, for how long will Sun keep its head deep in the sand like there is no AOP in java land? Do we have to see AOP in C# first?

    Congrats to both teams!
    Hristo
  15. Where are Sun and JCP?[ Go to top ]

    Hi All

    I've been kind of busy with another TSS thread today, but this news is very important too. Congratulations to both organizations.

    Kind regards, Robin.
  16. Where are Sun and JCP?[ Go to top ]

    Do we have to see AOP in C# first

    I am torn about that one. There are AOP implementations in .Net now. Spring.Net, etc. but not to the level of muturity, flexibility (the different flavors) and big "vendor" support that exists in the Java community. On the .Net side, the big push/bulk of the work will need to come from Microsoft. Maybe they are working on it, but it looks like their concentration is on getting updates of current products done. They have a lot to do in that department. And I am not sure if they would think AOP is enough bang for the buck for them to put it near the top of their list (In word and in deed).

    Why am I torn? I like it that Java has something great that .Net [effectively] doesn't have (at least not the level). On the other hand I do .Net work and talk with others who do. And some solutions to some of our issues involve AOP. Also, I can see many who look to Microsoft for direction and if Microsoft isn't talking about it, then it must not be good. (BTW, if they are working on/talking about it, please let me know)
  17. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    This is great news for AOP! Keep up the god work Adrian, Jonas, Alex and all the other great people involved!
  18. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    Congratulations!
  19. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    This is a good for the community as it will most likely fill in the role of a defacto standard for AOP in Java ...
  20. AspectJ and AspectWerkz Merge Forces[ Go to top ]

    This is a good for the community as it will most likely fill in the role of a defacto standard for AOP in Java ...

    Indeed. In view of developments in the JCP highlighted in another thread it seems that these sort of standards are going to be of increasing importance in the Java community. This is good news.
  21. What about them?[ Go to top ]

    "That's the event that kick-started the relationship between AspectJ and Spring". So whas it Spring or AspectWerkz?

    Anyway, how will AspectJ 5 and Spring AOP mesh together? Will Spring just adopt AspectJ 5 instead of their own stuff or what?

    What about JBoss AOP? Will there be a war between them and "2 of the leading J2EE vendors"?

    Nice merger. But still more questions than answers.
  22. What about them?[ Go to top ]

    Stasys,

    The full details of the integration of Spring with AJ and AW have yet to finalized. With AJ, it will be possible to configure most if not all your aspects using Spring Dependency Injection.

    We don't plan to completely replace Spring AOP with AJ underneath since we want to keep runtime weaving. This is likely where AW comes in with its excellent proxy support.

    The key thing in Spring is keep the use of AOP focused on coarse-grained services such as transactions and keeping this easy to use. Also we want Spring to help you configure any fine-grained aspects using Dependency Injection, reducing the need for any non-Spring aspects to be configured differently from the rest of your app.

    Rob
  23. AspectJ 5, Spring, and JBoss[ Go to top ]

    "That's the event that kick-started the relationship between AspectJ and Spring". So whas it Spring or AspectWerkz?

    TSS was where Rod Johnson and I first got together, and it's the place where I first deeply understood the value of bringing the differing approaches together in some way.
    Anyway, how will AspectJ 5 and Spring AOP mesh together? Will Spring just adopt AspectJ 5 instead of their own stuff or what?

    There's already one reply from the Spring guys in this thread, so let me just add a little to that. We're working together to ensure that AspectJ aspects can easily be configured by Spring (a lot of that work is done - see the examples in the Eclipse AspectJ book for example), and we've some more in the pipeline for aspects with instantiation models other than singleton. The other key thing we're doing in AspectJ is opening up our pointcut parsing and matching engine. Spring will then be able to take advantage of that to use the AspectJ pointcut language (or a defined subset) in its own AOP framework. What's nice about this is that you can start off just using Spring AOP, and if you ever need to get into more fine-grained aspects in your application the pointcuts you've already written, and the skills you've acquired in learning to write pointcuts, can just move straight across.
    What about JBoss AOP? Will there be a war between them and "2 of the leading J2EE vendors"?

    There is absolutely no intention on my part to start any kind of war :). I think what we're doing is good for JBoss, and that what JBoss is doing is good for us. Let me explain what I mean by that. JBoss heavily promote aspects and AOP as a value-added feature of their application server. Seeing other players in the industry agreeing that AOP is important and working together on it should (I hope) send an even stronger message to corporate customers that AOP is not just some new shiny toy, but a serious technology that they can consider adopting. I would expect this to help JBoss in their promotion of their app server. As to why I say what JBoss is doing is good for us... JBoss are heavily promoting aspects as part of a J2EE programming model, and are showing how AOP can be integrated into application servers and programming models in a deep way. They talk about aspects at their user events, and continue to innovate in the development of their aspect libraries. This can only be good for the field of AOP as a whole.

    I also personally believe there's an interesting synergy between the emphasis of what the AspectJ 5 project is doing and what JBoss is doing. Our focus has been on building great (we hope ;) ) aspect-oriented programming tools and all the support needed to go around that (IDEs, books, consultants, education, articles, ...). To me, the real value add in JBoss is the aspect library.

    I'd be interested in discussions with any open source project that wants to use AspectJ 5 as the foundation for its aspect-oriented features. Be that JBoss, Geronimo, JOnAS, ... Of course, AspectJ applications can already be deployed and run on these platforms, so we're talking about what more could be done on top of that.
  24. What about them?[ Go to top ]

    Will Spring just adopt AspectJ 5 instead of their own stuff or what?
    Spring AOP and AspectJ are not in the same space, so one can't replace the other. For many J2EE applications, the purely proxy-based approach of Spring AOP is the most appropriate. For "full-blown" AOP we believe that the AspectJ/AspectWerkz product will be the definitive implementation, and we will ensure that Spring users can adopt it within Spring-based architectures, with full support for dependency injecting aspects etc. Including using Spring AOP and AspectJ together (we'll be announcing more on that).

    Rgds
    Rod
  25. What about them?[ Go to top ]

    Will Spring just adopt AspectJ 5 instead of their own stuff or what?
    Spring AOP and AspectJ are not in the same space, so one can't replace the other. For many J2EE applications, the purely proxy-based approach of Spring AOP is the most appropriate. For "full-blown" AOP we believe that the AspectJ/AspectWerkz product will be the definitive implementation, and we will ensure that Spring users can adopt it within Spring-based architectures, with full support for dependency injecting aspects etc. Including using Spring AOP and AspectJ together (we'll be announcing more on that).RgdsRod
    AspectWerkz announced recently that they support 'proxy' model,so why do not use AW?
  26. Name of AspectJ 5[ Go to top ]

    Hi

    I think that the merger of AspectJ and AspectWerkz is a really good thing.

    However, I'm not so convinced about the name. Why AspectJ 5? When Sun did this for J2SE 5, it created endless confusion with what to call it: is it Java 5? Java 5.0? Java 1.5.0? Java 2 5.0?

    I'm also noticing in (The AspectJTM 5 Development Kit Developer's Notebook ) that the version is called 1.5.0.

    When it goes to 1.5.0, does it become AspectJ 6?

    So this merger seems to be following the same route of confusion that J2SE 5.0 did.

    Additionally, does AspectJ 5, v1.5.0 suggest/imply too close a link with J2SE?

    Am I missing something - is there a good reason to call it "AspectJ 5"? Or am I right that it's just going to lead to confusion?

    Calum