BEA hires Mr. AspectWerkz: getting even more serious about AOP?

Discussions

News: BEA hires Mr. AspectWerkz: getting even more serious about AOP?

  1. It has been heard on the grapevine that BEA recently hired Jonas Bonér, the founder of the much praised AspectWerkz AOP framework.

    This is a great addition to the BEA team (which includes our beloved Cedric Beust), and it will be exciting to see if Jonas' addition will push BEA more into AOP.

    Note: BEA recently released a set of reusable AspectJ pointcuts.

    Cameron Purdy blogged about the new hire at: AOP Hard On!

    Threaded Messages (40)

  2. Open Source is your best CV[ Go to top ]

    People behind successful Open Source projects prove their skills indirectly through the software they have made public for free.

    In addition to that, they are also good PR, because they are well-known and have "street cred" in the software developer community.

    It is enlightening that more and more companies realise this and are looking for talent in the Open Source scene. It keeps the breed alive, and hopefully encourages more people to do Open Source.

    Congratulations Jonas!

    Cheers,
    Aslak
  3. Great for Jonas. I hope this means he can work on AspectWerkz full time rather than burning the midnight oil.

    Bill
  4. Old news?[ Go to top ]

    Hasn't Jonas been a BEA employee for a long time on the JRockit team?

    Bill
  5. Old news?[ Go to top ]

    I don't think so. Jonas was jodeling in Austria for a while but he did not well, so the Austrians kicked him out and now he's back north (where all good AOP is made :)
  6. Old news?[ Go to top ]

    Bill: Hasn't Jonas been a BEA employee for a long time on the JRockit team?

    In June he blogged: "Two weeks ago we moved back to Sweden (after a year and a half in Austria) and I'm currently looking for a new job." So it doesn't appear that he has been "a BEA employee for a long time."

    In related news, Bill Burke was just hired by JBoss Group. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  7. Old news?[ Go to top ]

    In related news, Bill Burke was just hired by JBoss Group. ;-)


    LOL. I will hire Bill Burke ANY DAY AT ANY PRICE :)

    my day will be complete when I see the crazy guy from our thread posting conspiracy theories on how BEA will force Jonas to work on BEA.

    He he how can I leapfrog BEA without having them copy us WITHIN THE DAY.

    LOL
     
    >
    > Peace,

    love and good code,

    marcf

    > Cameron Purdy
    > Tangosol, Inc.
    > Coherence: Easily share live data across a cluster!
  8. Old news?[ Go to top ]

    He he how can I leapfrog BEA without having them copy us WITHIN THE DAY.


    Easy, but first you must leapfrog them.

    Bill
  9. Old news?[ Go to top ]

    Does anyone know if BEA will also be using aspectwerkz now (much like jboss is using Hibernate)?
  10. Old news?[ Go to top ]

    He he how can I leapfrog BEA without having them copy us WITHIN THE DAY.

    >
    > Easy, but first you must leapfrog them.
    >
    > Bill

    Somebody is spoofing my name here..."Bill Burke ". Is that you Mike Spille? ;> I know you want to be me, but you can't ;-p

    The "Real" Bill Burke
  11. Old news?[ Go to top ]

    "Somebody is spoofing my name here..."Bill Burke ". Is that you Mike Spille? ;> I know you want to be me, but you can't ;-p "

    Yeah, delete the fake Bill. Pretending to be Bill Burke's wife is ok, but a trailing blank is simply lame.
  12. Old news?[ Go to top ]

    Sorry to disappoint, but it's not me doing it. I've only ever used one name on TSS.

        -Mike
  13. Old news?[ Go to top ]

    marc: my day will be complete when I see the crazy guy from our thread posting conspiracy theories on how BEA will force Jonas to work on BEA.

    I've got to admit, that's pretty damn funny ;-)

    marc: love and good code, marcf

    ... but preferably not at the same time.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  14. I am actually a newbie to AOP and its Implementaions, but rventually i have found a lot of potential in it and looking forward to use it in our future products. From the documentation available at AspectWerkz, this implementation seems pretty intresting.


    /IDEA
  15. AOP - Some concerns[ Go to top ]

    I don't know if this is the right thread, but I've some problems with AOP and the usage of it in every day projects.

    I've played with AspectWerkz for a while and it is nice. I understand that it is very cool to introduce new functionality to objects at runtime, BUT only to Joinpoints and they can be only assigned to methods, variables and throwables. The next point is that the information of Aspects is not available at development time.

    An example of this problem:

    One of the most often used examples for AOP is a Logging mechanism. Logging for me is a feature that I use for tracing, debugging, info and errorhandling. What you can do with AOP is automatically log all method calls, variable assignments (except the methods from the core Java API) and thrown Exceptions ...nice, but this is not a complete Logging mechanism. What I can't to with an AOP logger is to write my own trace and debug informations in the code anywhere I want...
    If I want to provide a central Logging service that can be used by all developers, it is not possible. There is nothing like Logger.getLogger().debug("").

    So beside some aspects that can be used to build an AppServer and make feature from EJBs (TX, Persistence, Security) available for POJOs, because there the Joinpoints fit the requirements, where are the advantages for me as a developer for every day problems?
     
    Mirko
  16. AOP - Some concerns[ Go to top ]

    One of the most often used examples for AOP is a Logging mechanism. Logging for me is a feature that I use for tracing, debugging, info and errorhandling. What you can do with AOP is automatically log all method calls, variable assignments (except the methods from the core Java API) and thrown Exceptions ...nice, but this is not a complete Logging mechanism. What I can't to with an AOP logger is to write my own trace and debug informations in the code anywhere I want...

    > If I want to provide a central Logging service that can be used by all developers, it is not possible. There is nothing like

    There would be if used a decent AOP framework. To do this in C# whould be minutes work.
  17. AOP - Some concerns[ Go to top ]

    There would be if used a decent AOP framework. To do this in C# whould be minutes work.

    That sounds promising, but you're a bit "lite" on details. Why don't you provide some more information to back your assertion up.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  18. AOP - Some concerns[ Go to top ]

    That sounds promising, but you're a bit "lite" on details. Why don't you provide some more information to back your assertion up.


    The original quote
    <quote>
    Exceptions ...nice, but this is not a complete Logging mechanism. What I can't to with an AOP logger is to write my own trace and debug informations in the code anywhere I want.
    </quote>

    Just add attributes containing the custom debug informations to all the fields/properties/methods of interest. Than, when you intercept something in the AOP logging framework you check for those attributes. You can determine (to some extend, of course) your point in the application execution tree by analyzing the stack trace and provide _context dependant_ logging. The stack trace trick is simple and not that powerful, but a logging framework is not rocket science.
  19. !AOP[ Go to top ]

    Edward: Just add attributes containing the custom debug informations to all the fields/properties/methods of interest. Than, when you intercept something in the AOP logging framework you check for those attributes. You can determine (to some extend, of course) your point in the application execution tree by analyzing the stack trace and provide _context dependant_ logging. The stack trace trick is simple and not that powerful, but a logging framework is not rocket science.

    That is very nice, and I have done similar things before in C#.

    Unfortunately, it's not AOP. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  20. !AOP[ Go to top ]

    Edward: Just add attributes containing the custom debug informations to all the fields/properties/methods of interest. Than, when you intercept something in the AOP logging framework you check for those attributes. You can determine (to some extend, of course) your point in the application execution tree by analyzing the stack trace and provide _context dependant_ logging. The stack trace trick is simple and not that powerful, but a logging framework is not rocket science.

    >
    > That is very nice, and I have done similar things before in C#.
    >
    > Unfortunately, it's not AOP. ;-)
    >
    > Peace,
    >
    > Cameron Purdy
    > Tangosol, Inc.
    > Coherence: Easily share live data across a cluster!

    It's the blindest AOP on earth, but it is AOP. I have message interception and the concept is AOPish too.
  21. Smalltalk.NET[ Go to top ]

    Cameron,

    There are people implement Smalltalk into .NET. Some have a functioning meta-object layer. Haven't looked into how far the LISP people have gotten.

    Cheers,
    Greg
  22. AOP - Some concerns[ Go to top ]

    After spending plenty of time with AOP I would certainly say that logging is a VERY poor example. Profiling is okay, as is tracing method calls and returns, but logging interesting events and information in the detail of your methods is not a good use of AOP and something that you will still have to do by hand. If you think about it, how can an AOP system ever know when some state in the middle of a method is valuable enough to be worth logging?

    My personal view is that AOP is fantastic for technical (horizontal) cross-cutting concerns that you mention such as transactions, security, caching, persistence, lifecycle etc. As it stands at the moment most high-level business logic developers probably shouldn't need to be particularly aware of the details of AOP other than having the knowledge that their particular method or class might be used in a cache/transaction/profiler/xyz and make sure that it does not do anything that obviously prevents this.

    Perhaps in the future we might see more vertical cross-cutting, such as using AOP to avoid tangling of use-cases and so on. (For example, I write a use case to post a message to the forum and another to apply filters to some text then use AOP to apply filtering to the message posting without altering the original message posting code.) However, at the moment there is probably too little AOP experience and too few people who fully understand all the nuances and implications to try this on a large production system. Many developers seem to struggle with basic oo concepts, without introducing yet another way of doing things!
  23. AOP - Some concerns[ Go to top ]

    After spending plenty of time with AOP I would certainly say that logging is a VERY poor example. Profiling is okay, as is tracing method calls and returns, but logging interesting events and information in the detail of your methods is not a good use of AOP and something that you will still have to do by hand. If you think about it, how can an AOP system ever know when some state in the middle of a method is valuable enough to be worth logging?


    I don't whant the AOP system to know when I want to log, I want to use the aspect, or better the introduction of the logger aspect in my code to log when I want to log. I think that AOP is not about a central system knowing what and when to do things for me. It's more like a new structuring for cross cutting concerns that can be business aspects, too. Intoroductions sound so nice, but if you look in depth into them than you see that no introduction to an object is visible at development time...

    > My personal view is that AOP is fantastic for technical (horizontal) cross-cutting concerns that you mention such as transactions, security, caching, persistence, lifecycle etc. As it stands at the moment most high-level business logic developers probably shouldn't need to be particularly aware of the details of AOP other than having the knowledge that their particular method or class might be used in a cache/transaction/profiler/xyz and make sure that it does not do anything that obviously prevents this.

    The problem is that with byte code manipulation it is possible that errors occur in code they don't know that it even exists. I am very sceptic with byte code manipulation, especially because of security issues, debugging and maintanance.
    I don't see any superior feature of AOP than Proxies have. All the transaction, security, caching, persistence stuff can be made with Proxies. They are much better debuggable than bytecode manipulation and are very flexible. I think Rickard said once, that everything can be done with a layer of proxies...maybe he realized his AOP framework with Proxies???

    > Perhaps in the future we might see more vertical cross-cutting, such as using AOP to avoid tangling of use-cases and so on. (For example, I write a use case to post a message to the forum and another to apply filters to some text then use AOP to apply filtering to the message posting without altering the original message posting code.) However, at the moment there is probably too little AOP experience and too few people who fully understand all the nuances and implications to try this on a large production system. Many developers seem to struggle with basic oo concepts, without introducing yet another way of doing things!

    So you are exactly decribing the problem I have with AOP. It is used for filtering methods...use Proxies for that! There is a lot of experience with that technology and the byte code that is executed is the one you have compiled...

    Mirko
  24. AOP - Some concerns[ Go to top ]

    So you are exactly decribing the problem I have with AOP. It is used for filtering methods...use Proxies for that! There is a lot of experience with that technology and the byte code that is executed is the one you have compiled...

    >
    > Mirko

    My sentiments exactly.

    Bob
  25. AOP - Some concerns[ Go to top ]

    Hi Mirko,

    So you are exactly decribing the problem I have with AOP. It is used for filtering methods...use Proxies for that! There is a lot of experience with that technology and the byte code that is executed is the one you have compiled...

    AOP is a conceptual way of doing something. Proxies are an implementation. To some extent, AOP could be implemented using Proxies, for example.

    The real question I have with AOP is how we can get the flexibility / power that it could provide without the corresponding headache that is exhibited by several ealy AOP and AOP-like implementations. I don't think gluing AOP onto Java is any more natural than gluing objects onto C, unfortunately. (And regarding C#, the same holds true, despite the fact that the design of C# was not at all in the slightest nosireebob copied from Java.) What we end up with, due largely to the expressive limits of the language, is a focus on interception, not AOP per se.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  26. AOP != Filtering methods ;)[ Go to top ]

    I don't think that AOP is about filtering methods. Sure, you can use AOP to do this, but that isn't what AOP is. AOP is giving us a way to capture pointcuts, and that is where the power will come in. At the moment it is "easy" to see the low hanging fruit of system aspects (tx, persistance, basically the EJB stuff), but we will find much more. This is comparable to UI showing us the power of OOP.

    If you take a look at some other work, such as seeing the "Design Patterns" implemented with AOP you see some cool stuff. With items like the worm-hole affect showing up, we are seeing clean ways to do work. AOP isn't a silver bullet. My biggest fear is that AOP will become like OOP, and everyone will start going crazy implementing their entire system as aspects. AOP can work nicely with your OO model, and should be used sparingly, but where it keeps everything cleaner.

    I can't wait to see where we run with it!

    Dion

    ps. There is nothing stopping you from grabbing a Logger object and calling methods on it :)
  27. Filtering[ Go to top ]

    Cameron, Dion,

    maybe it was not clear what I meant. I didn't say that AOP is filtering methods. But actually every software I see using AOP is doing just filtering with it.

    I understood AOP more as a concept. For me an aspect could be every "class" that os crosscutting what means that it is some functionality that is used by many components in a software system.

    With the current implementations like AspectWerkz or JBoss AOP, in my opinion you are not able do realize these concepts. Actually you are able to filter methods, variable assignments and Throwables...and you get a lot of XML files describing the mappings, pointcuts, aspects, etc.

    I agree with Cameron. Maybe there should be a AOP programming language and we shouldn't try to make Java one...Java didn't really managed to get object-orientated :-) And by the way, I love that it isn't really OO...

    The truth is in the code.

    Mirko
    :wq
  28. Filtering... now :)[ Go to top ]

    Mirko -

    You are right in that a lot of people are using "AOP" for interception. This is because we are in very early days :) The nice thing about AOP is that you CAN dip your feet in the water. You can start off playing with it JUST in development (tracing, code policy, standards, etc). Then when feeling more comfortable you can do more. This is nice IMO. As practitioners, we need to go slowly, else we will do the wrong thing and then complain that "AOP SUCKS", just like we saw some people saying "OOP SUCKS" because the designs had insane inheritance heirachies :)

    D
  29. Time to unlearn OOP[ Go to top ]

    Mirko: I understood AOP more as a concept. For me an aspect could be every "class" that os crosscutting what means that it is some functionality that is used by many components in a software system.

    I think part of the challenge with understanding AOP is that people look at AOP as just what you said: "some functionality that is used by many components in a software system". I would call that a library, or a re-usable component, and it has little-to-nothing to do with AOP.

    What AOP is, if I may for a moment pretend to know something about it, is the ability to apply some common functionality to (potentially) many components in a software system. The difference is very subtle in how it is described, but it makes a fundamental difference.

    Part of what I heard in the criticism of the JBoss AOP implementation (for example) was that they were focused on how to use a common feature from many components, instead of how to apply a common feature to many components. So instead of thinking about how to describe where the feature needs to be applied, they concentrated on how those components would be able to access the feature. (The wording of the criticism, if I remember correctly, was that the JBoss implementation was too focused on interception.)

    It is similar, in my mind, to how C programmers treated C++ when they first saw it: They tried to explain objects in terms of functions, which was correct in terms of how the CPU would see the code, but not correct for how the developer should model the software. Similarly, Java programmers are trying to explain aspects in terms of objects. We are, as it were, limited by our own knowledge.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  30. Time to unlearn OOP[ Go to top ]

    Cameron, your analogy to C and C++ are dead on. My own example is this: Interception is to AOP what structs with embedded function pointers is to classes in C++. Yes, both give you polymorphism, and both give you code and data packaged together. But the struct/fp approach is missing so much of the real power in the C++ class.

    Interception is like that, when compared to something like AspectJ.

        -Mike
  31. Time to unlearn OOP[ Go to top ]

    Cameron, your analogy to C and C++ are dead on. My own example is this: Interception is to AOP what structs with embedded function pointers is to classes in C++. Yes, both give you polymorphism, and both give you code and data packaged together. But the struct/fp approach is missing so much of the real power in the C++ class.

    >
    > Interception is like that, when compared to something like AspectJ.
    >
    >     -Mike

    I presume that by polymorphism you mean the old definition(e.g. from SL5) not the OO one. If you think in a COM/VB fashion, I don't see any difference between a C++ class and a struct/fp approach. Inheritance being the big difference(I presume), I fail to really grasp the depth of Cameron's analogy. Can you please elaborate/enlighten?
  32. Time to unlearn OOP[ Go to top ]

    \DODO DODO\
    I presume that by polymorphism you mean the old definition(e.g. from SL5) not the OO one. If you think in a COM/VB fashion, I don't see any difference between a C++ class and a struct/fp approach. Inheritance being the big difference(I presume), I fail to really grasp the depth of Cameron's analogy. Can you please elaborate/enlighten?
    \DODO DODO\

    I'm going from a rather general definition of polymorphism: behavior of an "object" varies depending on its type. The variance is built into the object itself, rather than relying on external mechanisms (e.g. no switch/if-then-else statements).

    In a struct/fp approach, the function pointers give you the polymorphism. You may get the worlds-poorest-man version of inheritance by embedding a "parent" struct into a "child" struct, and relying on ANSI C's struct alignment rules and casting as appropriate. In the end, you do a fair amount of grunt work, and you get polymorphism.

    What you lose is encapsulation, real inheritance, abstract members, constructors, and many other OO bits.

    Comparing this with interceptors and AOP - just like polymorphism is only one piece of the OO puzzle, for a long time many people thought that's the main thing it gave you. And they thought that by using a very low-level construct like function pointers embedded in structs that they were reaping the majority of the benefit of OO without all the full-blown OO hassle.

    In AOP, people think interception is the main thing you get, and by using low-level interception techniques that they are reaping the majority of the benefit of AOP without all the full-blown AOP hassle.

        -Mike
  33. Time to unlearn OOP[ Go to top ]

    I think it's been mentioned many times that AOP is basically interception + rich pointcut model. Without each of these two constituents - it’s not an AOP at least in the form we understand it right now.

    And as far as topic I think BEA’s hiring of AspectWerkz tells at least something about AspectJ…

    Regrads,
    Nikita.
    Fitech Labs.
  34. Time to unlearn OOP[ Go to top ]

    And as far as topic I think BEA’s hiring of

    >AspectWerkz tells at least something about AspectJ…

    Hrm. What does it tell us about AspectJ ???
  35. Time to unlearn OOP[ Go to top ]

    What AOP is, if I may for a moment pretend to know something about it, is the ability to apply some common functionality to (potentially) many components in a software system. The difference is very subtle in how it is described, but it makes a fundamental difference.


    >
    > Part of what I heard in the criticism of the JBoss AOP implementation (for example) was that they were focused on how to use a common feature from many components, instead of how to apply a common feature to many components. So instead of thinking about how to describe where the feature needs to be applied, they concentrated on how those components would be able to access the feature. (The wording of the criticism, if I remember correctly, was that the JBoss implementation was too focused on interception.)

    Cameron,
    Is there a way you could elucidate the above 2 paragraphs with an example? If you could, it would improve the clarity of understanding for novices, i believe!
  36. Time to unlearn OOP[ Go to top ]

    Jagan: Is there a way you could elucidate the above 2 paragraphs with an example? If you could, it would improve the clarity of understanding for novices, i believe!

    First, I'll state that most people are true novices at best with respect to AOP. Probably only a handful of people in the world have been able to grasp a large portion of what AOP could become, and I don't count myself in that group, so any answer you get from me is going to be novice in nature itself.

    Second, just to be clear, I was careful not to personally criticize the JBoss work. It (the JBoss implementation) would only be negative if it limited the scope and vision of other projects, which seems to be the opposite if anything of what is actually occurring at this point in time. Hopefully Bill will adopt ideas from some of the other projects where appropriate, and maybe introduce a few new ones in the process.

    So, what I said was: "What AOP is .. is the ability to apply some common functionality to (potentially) many components in a software system."

    What this means, and what the term "cross cutting" is used to describe, is the concept that, out of thousands of classes with tens or hundreds of methods in an application, you want to select particular items to enhance in some manner. The question of how you select them is of some debate at this point, but think of how you have to sometimes go in to an application and add some functionality to all the classes that happen to do X or Y or Z ... in other words, think of how you work because that is what AOP is trying to help with. Simple examples are "all my servlets that store something in the session" or "all my value objects that I use to transfer persistent data". What I've seen so far with the existing implementations is that you specify the methods themselves, for example by identifying an interface/method combination, or using a regular expression to specify method names, or listing the method names in an XML file, or using attributes. However, I think that obscures what is actually being attempted to be accomplished, which is the description of the functionality in the application that you want to apply a common "addition" or "fix" or "modification" to.

    It should be noted that you can accomplish this today by going into the 40 places that you select and add a snippet of code that says "if (enable_special_functionality) { shared_component.foo(this); }" or whatever it takes to implement the functionality. In fact, this is half of the value of refactoring, because (for example) when you have to pass a second parameter, you have to add it to the one foo() method and go change 40 places that call it.

    What AOP allows is for you to describe those 40 places (hopefully in the abstract -- without actually listing them) and then describe the functionality that you want to apply to those objects/methods.

    In a way, it is the inverse of inheritance. In inheritance, one can place shared functionality in a base class and override it as desired with concrete/specific implementations. With AOP, one can can apply shared functionality on top of (in front of or around) concrete/specific implementations.

    Hopefully this makes everything perfectly opaque.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  37. AOP != Filtering methods ;)[ Go to top ]

    My biggest fear is that AOP will become like OOP, and everyone will start going crazy implementing their entire system as aspects. AOP can work nicely with your OO model, and should be used sparingly, but where it keeps everything cleaner. (Dion Almaer)


    No need to fear that. I implemented a whole content management system using AOP, and I must say it works quite well, and it's a lot more mantainable, testable and even faster, I think, than it would be if I was using just pure OOP or OOP with some AOP sprinkled on top.

    AOP has its uses, but it's not something we should fear using, or keep pondering about it too much. If it 'feels' easier to do with AOP, then why not? Just scratch the itch, test it and document it well ;)
  38. AOP - Some concerns[ Go to top ]

    AOP is a conceptual way of doing something. Proxies are an implementation. To

    > some extent, AOP could be implemented using Proxies, for example.

    ...just as Jon Tirsen's Nanning (nanning.codehaus.org) does ;)
  39. AOP - Some concerns[ Go to top ]

    I don't see any superior feature of AOP than Proxies have. All the transaction, security, caching, persistence stuff can be made with Proxies. They are much better debuggable than bytecode manipulation and are very flexible. I think Rickard said once, that everything can be done with a layer of proxies...maybe he realized his AOP framework with Proxies???

    >

    Does it mean that there is nothing new under the Sun; as there used to be a saying that all computer science problems could be solved with additional level of indirection.

    oleg
  40. AOP - Some concerns[ Go to top ]

    I'm sure that with AspectJ (and probably the other frameworks), you could set the value of a message string in your code (where you would have put a full blown logging statement) and pick up the value of that variable in the aspect to be used in the AOP logging statement.
    Probably not pretty but I think it would work.

    Regards
    C.
  41. Will AspectWerkz die?[ Go to top ]

    I really like the AspectWerkz project. I hope that Jonas will still have time to work on it AND that BEA keeps it open source.

    Hans.