Jonas Boner has written an article called "Introducing HyperBeans – multi-dimensional POJOs," discussing a "framework for Symmetric Aspect-Oriented Software Development in plain Java (i.e. no extensions to Java is being used)." Symmetric aspects, in this context, are aspects written specifically for a given class such that they are compiled in with the original code yet retain the semantics of aspects.

This is in comparison to "asymmetric aspects," in which aspects are first-class elements in and of themselves, which means they can be applied to any other classes.

The HyperBeans are a "regular Plain Old Java Objects (POJOs), they are instantiated with new and you work with them just as with regular classes, no configuration file or similar is needed."

The join points are specified by annotations.

What do you think of the idea? Jonas takes no position as to whether asymmetric AOP (or "classic AOP") is better than symmetric models, but the symmetric approach discussed in this article certainly seems to be easier to use than external compilation steps. Do you see a use for this technology?

hehe...he said Jonas Boner

I must be missing something here but "aspects written specifically for a given class" seems inconsistent with the whole cross-cutting concerns foundation of AOP. Why introduce the complexity? If it's for a specific class, isn't it the concern of that class and wouldn't it better off in the class?

I think you are missing something.

An advice in a HyperBean can be applied to *any* *other* class. It all depends on the pointcut you bind the advice to. In this sense HyperBeans function just like regular AW/AJ/JBoss/Spring aspects.

Ok?

I must be missing something here but "aspects written specifically for a given class" seems inconsistent with the whole cross-cutting concerns foundation of AOP. Why introduce the complexity? If it's for a specific class, isn't it the concern of that class and wouldn't it better off in the class?

I agree here. Automatic cross-cutting is one of the biggest advantages of AOP for me; I'm very pleased to know that my security cross-cut automatically finds all methods it needs to be applied to; I hate the idea that I might have forgotten one because each method needs to be annotated (if I understand the symmetric approach correctly).

I must be missing something here but "aspects written specifically for a given class" seems inconsistent with the whole cross-cutting concerns foundation of AOP. Why introduce the complexity? If it's for a specific class, isn't it the concern of that class and wouldn't it better off in the class?

I agree here. Automatic cross-cutting is one of the biggest advantages of AOP for me; I'm very pleased to know that my security cross-cut automatically finds all methods it needs to be applied to; I hate the idea that I might have forgotten one because each method needs to be annotated (if I understand the symmetric approach correctly).

You are misunderstanding the whole thing.

The @Around/@Before/@After annotations are added to the *advice methods* (they give you a way of binding the advice body to a specific pointcut). You do *NOT* annotate the target methods/fields/classes etc. They are picked out (as usual) by the pointcuts (like in AspectJ etc.)

The @Around/@Before/@After annotations are added to the *advice methods* (they give you a way of binding the advice body to a specific pointcut). You do *NOT* annotate the target methods/fields/classes etc. They are picked out (as usual) by the pointcuts (like in AspectJ etc.)

I indeed misread the code, thanks for pointing that out. So maybe someone could explain in a little less conceptual terms what statement is trying to be put across? I can't seem to get my head around the issue here. Is this much more different than runtime weaving?

Tom

This is made possible thanks to runtime weaving. Runtime weaving is an enabler.
The main point there is that the developer does new the aspect, while all the assymetrical approaches quoted by Jonas do use other means like pointcut / joinpoint governed life cycle and creation / pooling of the aspect done only by the underlying AOP framework- thanks by some prior declaration (compiled information within the aspect, XML etc).

If you don't have runtime weaving, it is much more difficult - if not impossible in some cases - to achieve, as every time someone new what looks like an aspect (ie any class that has those annotations), then you need to update some internals etc.

Now can someone debate the following: is symetrical approach needed when IoC approaches implies a governance where you don't really explictly new your components?
What kind of IDE support can be provided to help understand what symetrical approach aspect crosscuts?

Now can someone debate the following: is symetrical approach needed when IoC approaches implies a governance where you don't really explictly new your components?What kind of IDE support can be provided to help understand what symetrical approach aspect crosscuts?

I would say that new:ing the aspect (hyperbean) is the only real clean way of getting IoC to work with aspects.

If you have that (as in HyperBeans, where the def is in annotations and the deploy is triggered when you new the bean), then they actually work out of the box with existing IoC frameworks (Pico, Spring, HiveMind etc.).

E.g. you can have the HyperBeans wired up with the regular beans just like usual.

Now can someone debate the following: is symetrical approach needed when IoC approaches implies a governance where you don't really explictly new your components?What kind of IDE support can be provided to help understand what symetrical approach aspect crosscuts?

I would say that new:ing the aspect (hyperbean) is the only real clean way of getting IoC to work with aspects.

I also think this is the cleanest way of applying an aspect to a single bean instance.

<bean name="foo" class="org.MyBean"/>

<bean name="aspect" class="org.MyHyperBean">
   <constructor>
      <param><inject bean="foo"/></param>
   </constructor>
</bean>

Pretty damn simple and cool Jonas. Nice work.

Unfortunately, this is just one use case of IoC and AOP integration. There's still the matter of configuring the aspects themselves and propagating the dependencies an aspect may have all the way up to the bean itself. For instance:

public class MyBean {
   @Tx(REQUIRED)
   public void myMethod() {...}
}

<bean name="foo" class="org.MyBean"/>

The @Tx triggers an the TX aspect. The Tx aspect is dependent on the TM, therefore "foo" should not be deployed until the TM is deployed. What I'm saying is that your IoC container still needs to be aware of AOP and HyperBeans only isolate IoC from AOP in one particular use case.

Bill Burke
JBoss Inc.

P.S. Hopefully I didn't babble too much.


 If you have that (as in HyperBeans, where the def is in annotations and the deploy is triggered when you new the bean), then they actually work out of the box with existing IoC frameworks (Pico, Spring, HiveMind etc.). E.g. you can have the HyperBeans wired up with the regular beans just like usual.

Thanks a lot for the feedback Bill.

I think that you are right, there still needs to be some knowledge about aspects in the IoC container for all use-cases to be addressed.

...or, could this be solved by introducing some generic precedance/ordering rules?

There is a lot more to think about regarding symmetric AOSD in general. I definitely do not have all the answers (yet :) ).

The main point there is that the developer does new the aspect, while all the assymetrical approaches quoted by Jonas do use other means like pointcut / joinpoint governed life cycle and creation / pooling of the aspect done only by the underlying AOP framework- thanks by some prior declaration (compiled information within the aspect, XML etc).

*Stutter*

Maybe I see life too simple (which often is a good thing). Cross-cutting, for me, means that somewhere in compile time all classes are scanned for patterns matching the cross-cut and the byte code is then altered to call the aspect. Or at runtime the classloader is enhanced by the AOP framework to alter the loaded classes on demand, according to whatever cross-cutting rules are defined (whether that is in an ASPECT class alike thing, XML file or annotations).

What we're talking about here, to me, resembles the latter.

The only new thing is that the cross-cutting rules are dynamic: as soon as a "blessed" class is loaded by the classloader (new), it must rescan all already loaded classes to determine if the new rules apply and then alter (weave) the byte code accordingly.

So dynamic cross-cutting rules.

Call me stupid; but assuming I am correct, I'm still missing the point, since this does not seem to be something very different from what already exists.

Now can someone debate the following: is symetrical approach needed when IoC approaches implies a governance where you don't really explictly new your components?What kind of IDE support can be provided to help understand what symetrical approach aspect crosscuts?

The "not explicitly new" problem I can follow, although I would expect the classloader to process the blessed class regardless on how it is created (new or reflection) and thus weave correctly.

Tom

Runtime weaving does not deal with class bytecode at all. It deals with the Just In Time compiler and code optimizer embedded in the JVM internals.

Say you want to intercept all calls to Foo.do(), including reflective ones. There might be thousands, in thousands of classes, and even there you won't see the one done reflectively. You just can't locate those places and flip the bytecode at runtime as you would do at loadtime (after all loadtime is just some variant of post-compile time).
And current so far implemented runtime-like approaches that actually do preparation with a bunch of if(isDeployed()) {...} cannot really scale.

Runtime weaving does enables to do that, seamlessly.
Symetrical approaches is thus a good fit with this but certainly there are many other uses cases you can think about.

Runtime weaving does not deal with class bytecode at all. It deals with the Just In Time compiler and code optimizer embedded in the JVM internals.Say you want to intercept all calls to Foo.do(), including reflective ones. There might be thousands, in thousands of classes, and even there you won't see the one done reflectively.

Okay. So another runtime hook-in is used, not the classloader but the JIT compiler. See, I learned something again today, and it explains a lot. Isn't our job just great :-). Anyhow, the JIT compiler seems to be a better location, since custom classloaders are found all over the place.

But I'm not sure I see your point on the thousands of usages of a method call being different in any weaving technique. If you need to catch a call on the caller's side (and not callee) then, well, you need to be at the caller's side. Right? I hope.

And I still don't get what is special about synchronous. Maybe I should stop trying. :-)

Tom

The concept of symmetric versus asymmetric aspects is very appealing on a 'philosophical' level. Though I find it hard to translate the idea of symmetric aspects to a mental view of what a program using them would look like.
Would the aspects be advising each other? Does that lead to cycles?
Do aspects themselves have a different set of joinpoints than objects?

If I understand correctly they can only be used on the JRocket VM. That's a bit limiting of course.

The concept of symmetric versus asymmetric aspects is very appealing on a 'philosophical' level. Though I find it hard to translate the idea of symmetric aspects to a mental view of what a program using them would look like.Would the aspects be advising each other?

Yes HyperBeans can advise each other. That is the point. It is symmetric. The aspect view and the "base" view are the same.

Does that lead to cycles?

Yes it can. But you can easily get cycles in asymmetric AOP as well (AspectJ, AspectWerkz, Spring, JBoss etc), if you advise a method that you invoke yourself in the advice. Then you need to handle that.

Do aspects themselves have a different set of joinpoints than objects?

No, there is no difference between aspects and base classes. They are the same.

If I understand correctly they can only be used on the JRocket VM. That's a bit limiting of course.

True. On the other hand it is only a prototype and shows the power of JRockit AOP in action.

It would be great if someone volunteered to help out on an impl based on bytecode instrumentation, JVMTI etc. If anyone is interested, please let me know.

Does it support some way of static crosscutting ?

Wow. I really pity the poor guy that has to come along afterwards and maintain this...