[timfox]

> > simply cannot do directly in java - like
> intercepting
> > field access.
>
> Hmmmm...then how come the code I just checked into
> the JBoss aop framework can intercept private and
> protected fields? In other words, you're wrong.
>

I mean without changing bytecode.

> > this is why you have to use hacks, ie byte code
> > engineering (whether you use aspectj, bcel or
> > javassist it is still byte code engineering), in
> > order to fudge the effect of aop.
>
> How is this fudging?

Ok, it's not fudging in the sense the effect is the same, the point I was (unsuccessfully) trying to make is since it's not supported in the syntax of the language it becomes a lot harder. Although you can of course pretty much always do what you want to do by "flipping up a meta-level" (changing bytecode), as you yourself have demonstrated.

[juha]

> Hmmmm...then how come the code I just checked into the
> JBoss aop framework can intercept private and protected
> fields? In other words, you're wrong.

That was not the point, as tim said. Of course you can modify bytecodes from Java. But your approach is no different from using AspectJ weaver or BCEL (which is what weaver uses internally). You're just using a different library...

The point is that eventually you want to move from using a library to incorporating the features into the language syntax. Java may be extended to support the features (going the way of Objective C or Object Pascal, or even C++ in some sense) but should aspects really prove themselves as an alternative approach to OOP then there will eventually be a replacement language.

Building AOP language today will probably end up in the land of Eiffels and Smalltalks -- very useful research but chances are it will not reach the mainstream. So extending Java or using aspects via a library reaches a broader audience. But as far as paradigms go, this is only a temporary solution. (cf. adding objects to C ==> C++)

[marc.fleury]

> talipozturk - there are certain aop things that you
> simply cannot do directly in java - like intercepting
> field access.

Like Bill pointed out we do that with bytecode enhancement of the loaded classes. This is a key feature for the "Persistence on JBoss" project.

> this is why you have to use hacks, ie byte code
> engineering (whether you use aspectj, bcel or
> javassist it is still byte code engineering), in

hack? why? all I need is to know when you access these fields (again for example for Caches on JBoss and Persistence on JBoss) so we can transparently maintain replicated/persistent state across JBoss instances and in cache. All that is transparent to the programmer. In fact with bytecode engineering this is as if it was a feature of the language itself almost.

> there is a fundamental paradigm shift here.

come on man, you are on JBoss TV :) smile and use words that make sense. Paradigm is greeeat, greeeat for me to poopa on!

> you cannot do aop natively in java because it is an
> object oriented programming language, it is not an
> aspect oriented programming language.

Ok frankly here I say Stop The BS and give me real life examples. I am not saying you are wrong I am just saying that you need to substancially back this claim. What is a "Aspect Oriented Language". Please!

> i can of course write a C program that simulates the
> effect of a C++ program.
> that is basically what is happening now, this is
> bleeding edge so the tools don't really exist, or
> uptake is tiny.

which is why we stay away from proprietary languages. I think languages are the most difficult thing to do and model and most of all MARKET. As pointed out in the rest of thread this is a call to become yet another dark language. Stick to java, if the end result is to be bytecode then start by coding in the language of the bytecode.

Give me examples of what the AspectJ language brings to the table above and beyond java. If we are in a case of 80/20 (meaning we can do 80% of what the other language does) then my choice is clear.

> by that time we will have converged on a defacto
> syntax, or maybe there will be a couple of
> competitors. but i am sure there WILL be a syntax, it
> will not be java programs with a few deployment
> descriptors.

well ok. One thing that I think is missing in the bytecode format is enhancing it with doclet stuff so that even the runtime bytecode has metainformation about the stuff. That would really mean that we can keep doclet tags as part of the source and we wouldn't have to do the extra compilation step. AFAIK this is a feature (nice feature) of C#.

Maybe we could take a lesson from MS?

> this is now, and i think jboss is probably making the
> right decision in NOT adopting the aspectj language,
> not because it is bad, or wrong in some way
> (talipozturk listen please) , but because it is just
> too early.

Oh Ok well glad to hear you think it is the right direction. Frankly ease of use is important here, the key to adoption. I am even thinking that marketing wise we want to tone down the "Aspect" stuff, it is sexy for the coneheads like us but I think it will scare everyone else.

> when the JSR comes out for the AOP extensions to java
> (which may well use the aspectj syntax), maybe then,
> but that is a long time off.

right we will be done with the standard by then :)

[marc.fleury]

> > JBoss aop framework can intercept private and
> protected
> > fields? In other words, you're wrong.
>
> That was not the point, as tim said. Of course you
> can modify bytecodes from Java. But your approach is
> no different from using AspectJ weaver or BCEL (which
> is what weaver uses internally). You're just using a
> different library...

It is different as plainly explained. In the case of field interception we are simply creating a delegation to the "InvokerHandler" equivalent. This IH is in fact a pure java class. You don't use the library (the framework does) as the end programmer you work java on field indirections.

> The point is that eventually you want to move from
> using a library to incorporating the features into
> the language syntax. Java may be extended to support
> the features (going the way of Objective C or Object
> Pascal, or even C++ in some sense) but should aspects
> really prove themselves as an alternative approach to
> OOP then there will eventually be a replacement
> language.

Examples please. Attributes in the body and translated in bytecode ala C# would be nice but I don't know what else? What is SOOO specific about the interceptors that they need their own language? Can we leave the meta-discussion behind and be specific?

> Building AOP language today will probably end up in
> the land of Eiffels and Smalltalks -- very useful

agreed,

> mainstream. So extending Java or using aspects via a
> library reaches a broader audience. But as far as
> paradigms go, this is only a temporary solution. (cf.
> adding objects to C ==> C++)

we agree but until I have so much pain and Microsoft markets a new language that will blow everyone away (meaning that at least offers real portability) I don't see that we need to call it "temporary" :)

I firmly believe that straight java will be enough for all our cases right now. It needs to be anyway so let's be positive, writing

/**
* @javadoc:jbossaop-scope:ALL-METHODS
* This hint gets lost in bytecode, oh well
*/

public object invoke(Invocation invocation)
{
System.out.println("WHY COMPLICATE THIS?");
}

marcf

[azakkerman]

> /**
> * @javadoc:jbossaop-scope:ALL-METHODS
> * This hint gets lost in bytecode, oh well
> */
>
> public object invoke(Invocation invocation)
> {
> System.out.println("WHY COMPLICATE THIS?");
> }
>
> marcf
>

Rickard already proposed a fairly simple solution of making xdoclet attributes accessible at run-time. Check out his weblog. (The idea is to store the attributes in a autogenerated class in serialized form and using a special class, say Attibutes.getAttribute(class, attributename).

[juhalindfors]

> What is SOOO specific about
> the interceptors that they need their own language?

I'm short on time so I don't have a full response for you right now. But here's a thought exercise for you to ponder over christmas:

What is so specific about semaphores that Java needs a 'synchronized' keyword?

Would you replace the 'synchronized' keyword with a semaphore framework? Why/Why not?

What are the implications of integrating with 3rd party components if they decided to use a different semaphore framework?

What is the likelyhood that Jakarta will pick our framework?

[juhalindfors]

> I think this is a place with .NET has an edge at the
> Virtual machine level.

Nope. JVM can do this just as easily. It is the Java programming language that has a problem.

[crazybob]

> Smart but not good enough, we are still talking about
> a pregeneration step and and a separate file (here a
> .ser). What this buys is bypassing the XML parsing
> and going straight to a class representation.

For what it's worth, you'd still need a preprocessor, but Java byte code has support for embedded attributes which we could load when we load the classes. No need for a separate file.

[spiffster]

It is a while away, but JSR 175 will add metadata to the Java language and is scheduled for JDK 1.5.

[marc.fleury]

I wasn't aware of that, and it is pretty cool. So for JDK1.5 we will simplify the metadata.

[slaboure]

I simply hope that the JSR will be as flexible as the .Net feature which is more than just adding tags: you can implement new tags (tags are more like taglibs), *and* you have a standard way to *override* these values at deployement time by new values. Thus, the standard mechanism used by code to get the value of the tags, will not only read a static value that has been set during the compilation step but will also look if the value has been overriden at deployment time (or at runtime).