TheServerSide at AOSD 2004

Discussions

News: TheServerSide at AOSD 2004

  1. TheServerSide at AOSD 2004 (14 messages)

    TheServerSide is taking part in this years Aspect-Oriented Software Development Conference, hosted in Lancaster, UK. It has been very interesting to see the mix of academia and industry/open source participation. We have written up the trends that are being discussed at the conference after day one.

    Read TheServerSide at AOSD 2004: Day One

    Threaded Messages (14)

  2. Annotations[ Go to top ]

    I am personally worried that I will see methods with huge amounts of @annotations (we are already seeing this in .NET).
    That's an interesting thought. To me, it sounds a bit like "The Java language supports the 'for' loop, and I am worried that soon, we will be seeing methods with huge amounts of 'for' loops"...

    More seriously, I understand your concern but we will all have to adjust.

    I predict that in a couple of years, most of the Java sources we read and write every day will contain all kinds of annotations, probably even mixing annotations from different domains.

    Get used to the "@" sign, it's going to become your new best friend.

    --
    Cedric
  3. Annotations[ Go to top ]

    Cedric -

    I know what you are saying. I agree that we are going to see a lot of annotations, and think that they are going to drastically change the way we develop, in a good way.

    With all things I just have concerns about us going too far. People are naturally keen to "play with the new toy" and feel that we are going to go through a learning curve where we work out when and how to use annotations.

    There is a lot of talk about how annotations fit in at AOSD, since they will drastically change all of the AOP projects. It will be very interesting to see how things pan out :)

    Dion
  4. Annotations[ Go to top ]

    What about separation of concerns? does annotation breaks that priniciple? If I add an annotation to my domain class, the annotation is related to that domain problem I'm trying to solve or the concerns that crosscut that domain class?

    I see AOP very interesting, but still believe that some core OO principles have not been used correctly and AOP guys are trying to invent a "new thing" before taking OO to the limit.

    Lester
  5. Annotations[ Go to top ]

    To me, it sounds a bit like "The Java language supports the 'for' loop, and I am worried that soon, we will be seeing methods with huge amounts of 'for' loops"

    I think that's a pretty fair comparison. A method that has one or two for loops can be elegant and powerful. If you see a dozen for loops in a single method, it becomes problematic because of readability and complexity.

    I agree with Dion that in some shops you are going to see many annotations in a single method. This is not an argument against supporting annotations, but this sort of abuse needs to be recognized as an anti-pattern.
  6. Annotations[ Go to top ]

    I think the problem won't be how many annotations you use for a method, but what kind of meta-information the annotations represent. There might be meta-information that strongly depends upon the environment(e.g. development, integration, production) in which you run your application. Inserting this kind of information directly to Java source files is (from _my_ point of view) the biggest mistake one could ever make. You should never forget what you put into your Java sources there: Information about information, i.e. information at a higher level of abstraction than your java code is. Specifying this information _outside_ of your code very often makes more sense than putting it _into_ the code.
  7. TheServerSide at AOSD 2004[ Go to top ]

    Great reporting!

    FWIW, I've blogged some thoughts about the coverage.
  8. TheServerSide at AOSD 2004[ Go to top ]

    Rickard,

       I have finally read your paper, and there is one thing I am not quite following. You provide an example of an EmailChangeTraceAdvice:

    public abstract class EmailChangeTraceAdvice
      implements Advice,Person
    {
      public void setEmail(String aEmail)
      {
        String oldEmail = getEmail();
        proceed();
        System.out.println("Email for "+this.getName()+" changed from "+
          oldEmail+" to "+getEmail());
      }
    }

       Very elegant, and refactoring-friendly. But how do I generalize this to provide ChangeTraceAdvice for an arbitrary group of setters?

       This seems pretty simple to do with the detyped invocations in several of the popular dynamic AOP frameworks out there. But with the abstract schema, it almost seems as if I would need to define a separate advice class for each and every setter (or at least every domain interface) in the system that I wanted to apply the ChangeTraceAdvice to. Can you clarify this?
  9. TheServerSide at AOSD 2004[ Go to top ]

    Rickard, I have finally read your paper, and there is one thing I am not quite following. You provide an example of an EmailChangeTraceAdvice:... Very elegant, and refactoring-friendly. But how do I generalize this to provide ChangeTraceAdvice for an arbitrary group of setters? This seems pretty simple to do with the detyped invocations in several of the popular dynamic AOP frameworks out there. But with the abstract schema, it almost seems as if I would need to define a separate advice class for each and every setter (or at least every domain interface) in the system that I wanted to apply the ChangeTraceAdvice to. Can you clarify this?
    Sure. It's like this: if you want to handle detyped invocations you use a detyped advice. If you want to handle typed invocations you use a typed advice. In other words, the abstract schema approach complements the detyped approach. It does not replace it.

    However, the invocation part is really just half of what the paper propose. The other part is how the advice access other methods on the invoked object. With a detyped approach you'd typically do something like "((MyInterface)Invocation.getCurrentProxy()).someMethod(arg1)", and with the solution described in the paper you'd do "someMethod(arg1)". We're using this technique with loads of advice now, and it is making the code much cleaner and less framework-dependent.
  10. TheServerSide at AOSD 2004[ Go to top ]

    In other words, the abstract schema approach complements the detyped approach. It does not replace it.
    Thanks, that's the part I was missing. So your framework supports both abstract schema and detyped invocation?
    The other part is how the advice access other methods on the invoked object... with the solution described in the paper you'd do "someMethod(arg1)". We're using this technique with loads of advice now, and it is making the code much cleaner and less framework-dependent.
    Sure, that part made perfect sense, and is very appealing. However, it is too bad that you can't reap those benefits in the cases where abstract schema does not scale, and you need detyped invocation.
  11. TheServerSide at AOSD 2004[ Go to top ]

    Thanks, that's the part I was missing. So your framework supports both abstract schema and detyped invocation?
    Absolutely. Both styles are very useful, and as I said, can be combined.
    Sure, that part made perfect sense, and is very appealing. However, it is too bad that you can't reap those benefits in the cases where abstract schema does not scale, and you need detyped invocation.
    Actually, at least with my current implementation, it's only the invocation handling using abstract schema that has higher overhead than the detyped approach. If a detyped advice uses abstract schema to access methods on the object that is just as fast as accessing and going through the proxy. In other words:
    public Object invoke(Invocation inv)
    {
      someMethod();
      return inv.next();
    }
    is just as performant as:
    public Object invoke(Invocation inv)
    {
      ((SomeInterface)Invocation.getCurrentProxy()).someMethod();
      return inv.next();
    }
    That part is mostly just syntactic sugar.

    But it of course also depends on your performance requirements. With typed advice my current implementation of abstract schema can handle 500k invocations/second of a helloWorld() method with one typed advice. That's good enough for quite a lot of applications.

    The only place, so far, where I *could* use abstract schema but haven't is for advice on the persistence manager services (i.e. create/load/store/remove type methods). I have a number of advice on such services which intercept only some of the methods, e.g. "load", which would gain syntactically from using abstract schema (I've already had a number of annoying bugs due to detyped PM advice making incorrect assumptions about the argument types). However, since those methods are called so often I haven't changed those advice to use abstract schema. But that's the only exception I have so far.
  12. TheServerSide at AOSD 2004[ Go to top ]

    With typed advice my current implementation of abstract schema can handle 500k invocations/second of a helloWorld() method with one typed advice. That's good enough for quite a lot of applications.
    I strongly agree. Sorry for being unclear; when I was talking about abstract schema not scaling, I was talking about scaling on complexity, not performance.

    In the original example, where I wanted to provide a generalized ChangeTraceAdvice, assume that I had 100 distinct domain interfaces that I wanted to apply this advice to. It appears with abstract schema that I would need to create 100 clases, each of which implements Advice and its corresponding domain interface.

    With detyped invocation, I could create a single advice class and use pointcut specification to apply across all 100 domain interfaces. I lose my refactoring support here, but overall I think detyped invocation scales better (on complexity) in this scenario.

    For advice that is not so generalizable, abstract schema looks very compelling.
  13. TheServerSide at AOSD 2004[ Go to top ]

    I strongly agree. Sorry for being unclear; when I was talking about abstract schema not scaling, I was talking about scaling on complexity, not performance.In the original example, where I wanted to provide a generalized ChangeTraceAdvice, assume that I had 100 distinct domain interfaces that I wanted to apply this advice to. It appears with abstract schema that I would need to create 100 clases, each of which implements Advice and its corresponding domain interface.
    Ok, then I'm with you. Yes, for those cases you wouldn't use abstract schema, at least not for the invocation part.
    With detyped invocation, I could create a single advice class and use pointcut specification to apply across all 100 domain interfaces. I lose my refactoring support here, but overall I think detyped invocation scales better (on complexity) in this scenario.For advice that is not so generalizable, abstract schema looks very compelling.
    Detyped advice "scales better" in the sense you describe, in the cases you describe, but on the other hand abstract schema "scales better" from a maintenance point of view, in the cases where you'd benefit from using it instead of the detyped variant. As I said, the two complement each other quite well, and both should IMHO be available.
  14. TheServerSide at AOSD 2004[ Go to top ]

    AOSD turned out to be a pretty good conference. Best part about it for me was meeting the AspectJ and AspectWerkz team. Adrian Colyer, Erik Hindsdale from AspectJ. Also brainstormed a lot with Jonas Boner and Alex Vasseur. Great guys. I'll blog about it when I get a chance....

    Bill
  15. JBossAOP 1.0beta[ Go to top ]

    Just wanted to let everyone know that we released JBoss AOP 1.0 Beta the week before AOSD.

    http://www.jboss.org/releases/aopbeta

    It was a massive overhaul, many many new features, and massive performance improvements.

    JBossCache 1.0 was also released, as well as JBoss 4.0 DR3. See our website for more details.

    Bill