aopalliance-discuss Mailing List for AOP Alliance (Java/J2EE AOP standard)

Hi,

Luckily I found this issue bellow on your mailing list. Although this topic is 
already quite old, I would like to ask if there ever was this update to get
the Apache 2 license for the AOP Alliance API.

Thanks,
Nik


--------------------------------------------------------------

If there are no objections, I will pull the trigger tomorrow (Friday)
morning. Again, this doesn't affect the intended rights of our users. It
just clarifies their rights and makes people more comfortable using our
API.

Bob

On Wed, Jul 22, 2015 at 5:31 PM, Bob Lee <crazybob@...> wrote:

> AOP Alliance contributors,
>
> Last week, an AOP Alliance API user reached out to me because their legal
> team took issue with our Public Domain "license." You might recall this
> same issue coming up a couple times before
> <http://sourceforge.net/p/aopalliance/mailman/search/?q=license>;. For a
> summary of the issue, see the Open Source Initiative FAQ
> <http://opensource.org/faq#public-domain>;.
>
> To remedy this situation, I propose that we keep the existing Public
> Domain "license" but also add an Apache 2 license (i.e. an actual license).
> Specifically, I would update the AOP Alliance home page to say that AOP
> Alliance is also licensed under Apache 2 (the same license used by Spring,
> JSR-330, Guice, etc.).
>
> Any objections? I suspect there won't be any because this doesn't actually
> affect the intended rights of our users.
>
> Thanks,
> Bob

If there are no objections, I will pull the trigger tomorrow (Friday)
morning. Again, this doesn't affect the intended rights of our users. It
just clarifies their rights and makes people more comfortable using our
API.

Bob

On Wed, Jul 22, 2015 at 5:31 PM, Bob Lee <cra...@cr...> wrote:

> AOP Alliance contributors,
>
> Last week, an AOP Alliance API user reached out to me because their legal
> team took issue with our Public Domain "license." You might recall this
> same issue coming up a couple times before
> <http://sourceforge.net/p/aopalliance/mailman/search/?q=license>. For a
> summary of the issue, see the Open Source Initiative FAQ
> <http://opensource.org/faq#public-domain>.
>
> To remedy this situation, I propose that we keep the existing Public
> Domain "license" but also add an Apache 2 license (i.e. an actual license).
> Specifically, I would update the AOP Alliance home page to say that AOP
> Alliance is also licensed under Apache 2 (the same license used by Spring,
> JSR-330, Guice, etc.).
>
> Any objections? I suspect there won't be any because this doesn't actually
> affect the intended rights of our users.
>
> Thanks,
> Bob
>
>
>

No objections here. +1 all the way!
On Wed, Jul 22, 2015 at 8:32 PM Bob Lee <cra...@cr...> wrote:

> AOP Alliance contributors,
>
> Last week, an AOP Alliance API user reached out to me because their legal
> team took issue with our Public Domain "license." You might recall this
> same issue coming up a couple times before
> <http://sourceforge.net/p/aopalliance/mailman/search/?q=license>. For a
> summary of the issue, see the Open Source Initiative FAQ
> <http://opensource.org/faq#public-domain>.
>
> To remedy this situation, I propose that we keep the existing Public
> Domain "license" but also add an Apache 2 license (i.e. an actual license).
> Specifically, I would update the AOP Alliance home page to say that AOP
> Alliance is also licensed under Apache 2 (the same license used by Spring,
> JSR-330, Guice, etc.).
>
> Any objections? I suspect there won't be any because this doesn't actually
> affect the intended rights of our users.
>
> Thanks,
> Bob
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>

AOP Alliance contributors,

Last week, an AOP Alliance API user reached out to me because their legal
team took issue with our Public Domain "license." You might recall this
same issue coming up a couple times before
<http://sourceforge.net/p/aopalliance/mailman/search/?q=license>. For a
summary of the issue, see the Open Source Initiative FAQ
<http://opensource.org/faq#public-domain>.

To remedy this situation, I propose that we keep the existing Public Domain
"license" but also add an Apache 2 license (i.e. an actual license).
Specifically, I would update the AOP Alliance home page to say that AOP
Alliance is also licensed under Apache 2 (the same license used by Spring,
JSR-330, Guice, etc.).

Any objections? I suspect there won't be any because this doesn't actually
affect the intended rights of our users.

Thanks,
Bob

Dear AOP Alliance contributors,

I'm about to include your software package, aopalliance into Fedora where it
can be used freely by anyone interested. During that process, concerns were
raised whether aopalliance is truly under public domain.

We checked your members page [1] and noticed that, among others, people from
central Europe (i.e. France, Switzerland and maybe others) contributed to
that certain piece of software. Unfortunately, public domain is not legally
accepted in most parts of Europe. We know for sure that in both, France and
Switzerland, public domain is not applicable. This normally means, that work
from people from those countries is under the normal, restrictive copyright
when those people claim to publish something under public domain - i.e. the
contrary of what they intended to do happens.

We clearly can't include software that is probably under strict copyright
into Fedora. Also, we thought we'd inform you about our concerns and suggest
you to think your licensing terms over. We'd appreciate if you could look
into common open source licenses and re-license your software after you've
carefully done so. There's common licenses out there, that give everyone the
same rights as public domain does - but is generally accepted, legal-wise.
One of those, the probably most-used is the MIT License [2].

I hope I was able to make myself clear, even though my English skills
certainly lack all that legal stuff - because IANAL (hint!) and TINLA (hint!
hint!)

Kind Regards,
Sandro / red

[1] http://aopalliance.sourceforge.net/members.html
[2] http://en.wikipedia.org/wiki/MIT_License

Thanks so much for the almost immediate responses (more than one!). Maybe
Legal don't like things that simple and straightforward. The problem is I
still need more information to answer their questions.

Thanks once again and again.

Alvin

On 5/19/07, Bob Lee <cra...@cr...> wrote:
>
> "Public domain" basically means it's about as free as it can get. Plus,
> there's not any real code--just APIs.
>
> IANAL.
>
> Bob
>
> On 5/18/07, Alvin Yong <al...@ic...> wrote:
> >
> > Dear Developers of AOP Alliance,
> >
> > We are recently challenged by our client's legal department and
> > sincerely need your help to clarify some questions. The background is that
> > we used Spring Framework in our development and consequentially involved the
> > aopalliance.jar in their core for our development of a critical
> > application for financial institutes. There are a few questions they urge us
> > to response.
> >
> >    1. Who is the author, IP owner, of the embedded aopalliance.jar in
> >    used by Spring Framework?
> >
> >    2. Does the stated arrangement at aopalliance.sourceforge.net, " *
> >    LICENCE*: all the source code provided by AOP Alliance is *Public
> >    Domain*", is applicable to that aopalliance.jar and meaning that
> >    we can deploy the module legally free of charge in our development?
> >
> >
> >    3. Is there any legal issue right now associated with the use of
> >    aopalliance.jar?
> >
> >
> > I hope you understand we, the developers, just want to work and kind of
> > dummy to react on issue like this. Please give us a hand at your earliest
> > convenience.
> >
> > Thanks in advance.
> >
> > Best regards,
> >
> > Alvin Yong
> > ICO Limited
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > aopalliance-discuss mailing list
> > aop...@li...
> > https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
> >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>
>

"Public domain" basically means it's about as free as it can get. Plus,
there's not any real code--just APIs.

IANAL.

Bob

On 5/18/07, Alvin Yong <al...@ic...> wrote:
>
> Dear Developers of AOP Alliance,
>
> We are recently challenged by our client's legal department and sincerely
> need your help to clarify some questions. The background is that we used
> Spring Framework in our development and consequentially involved the
> aopalliance.jar in their core for our development of a critical
> application for financial institutes. There are a few questions they urge us
> to response.
>
>    1. Who is the author, IP owner, of the embedded aopalliance.jar in
>    used by Spring Framework?
>
>    2. Does the stated arrangement at aopalliance.sourceforge.net, " *
>    LICENCE*: all the source code provided by AOP Alliance is *Public
>    Domain*", is applicable to that aopalliance.jar and meaning that we
>    can deploy the module legally free of charge in our development?
>
>
>    3. Is there any legal issue right now associated with the use of
>    aopalliance.jar?
>
>
> I hope you understand we, the developers, just want to work and kind of
> dummy to react on issue like this. Please give us a hand at your earliest
> convenience.
>
> Thanks in advance.
>
> Best regards,
>
> Alvin Yong
> ICO Limited
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>
>

May be you can raise this issue to Interface21 as well as they own the
Spring Framework, their legal counsel should be able to provide you
guidance on this as one of their dependencies.
Alex

On 5/18/07, Alvin Yong <al...@ic...> wrote:
> Dear Developers of AOP Alliance,
>
> We are recently challenged by our client's legal department and sincerely
> need your help to clarify some questions. The background is that we used
> Spring Framework in our development and consequentially involved the
> aopalliance.jar in their core for our development of a critical application
> for financial institutes. There are a few questions they urge us to
> response.
> 1. Who is the author, IP owner, of the embedded aopalliance.jar in used by
> Spring Framework?
>
> 2. Does the stated arrangement at aopalliance.sourceforge.net, " LICENCE:
> all the source code provided by AOP Alliance is Public Domain", is
> applicable to that aopalliance.jar and meaning that we can deploy the module
> legally free of charge in our development?
> 3. Is there any legal issue right now associated with the use of
> aopalliance.jar?
> I hope you understand we, the developers, just want to work and kind of
> dummy to react on issue like this. Please give us a hand at your earliest
> convenience.
>
> Thanks in advance.
>
> Best regards,
>
> Alvin Yong
> ICO Limited
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>
>

Dear Developers of AOP Alliance,

We are recently challenged by our client's legal department and sincerely
need your help to clarify some questions. The background is that we used
Spring Framework in our development and consequentially involved the
aopalliance.jar in their core for our development of a critical application
for financial institutes. There are a few questions they urge us to
response.

   1. Who is the author, IP owner, of the embedded aopalliance.jar in
   used by Spring Framework?

   2. Does the stated arrangement at aopalliance.sourceforge.net, "*
   LICENCE*: all the source code provided by AOP Alliance is *Public
   Domain*", is applicable to that aopalliance.jar and meaning that we
   can deploy the module legally free of charge in our development?


   3. Is there any legal issue right now associated with the use of
   aopalliance.jar?


I hope you understand we, the developers, just want to work and kind of
dummy to react on issue like this. Please give us a hand at your earliest
convenience.

Thanks in advance.

Best regards,

Alvin Yong
ICO Limited

I have just joined the AOP Alliance mailing list and read thought the
White paper (draft).
Found some typos along the way that can be corrected. :-)



"The Current Brakes To AOP"
..."was not well fitted in some environments having some kinds of
distribution and persistence cacabilities."

should read:

..."was not well fitted in some environments having some kinds of
distribution and persistence capabilities."



"What Shall AOP Alliance Specify Here?"
..."Some technical caracteristics may also have deep inpact on the
resulting system properties"

should read:

..."Some technical characteristics may also have deep impact on the
resulting system properties"



Regards,
-Alen Ribic

Pascal Costanza wrote:
> [Sorry, but I haven't followed the previous discussion.]
>=20
> The examples on your website are weird.
>=20
> - Under what circumstances do you think it makes sense that an aspect=20
> depends on the number of arguments a method receives? This seems=20
> arbitrary. Do you have an example?

Yes it is arbitrary. It is to illustrate that accessing joinpoint info=20
statically is a good thing. In AspectJ it seems that you have tree ways=20
for accessing jp-infos:

- dynamically and in a non-typed way with thisJoinPoint (slow and=20
dangerous at runtime)
- statically but generically (only for the part what can be done with=20
thisJoinPointStaticPart)
- using the pointcuts to bind variables (which always seemed strange to=20
me since it makes the pointcuts play two different roles: a crosscut=20
designator and a binding facility)

All these methods have different impacts on the aspect's performance and=20
design. They have to be used carefully by the programmer and any mis-use=20
can have the worse impacts...

With Spoon-AOP, it is clear from the beginning that there is only ONE=20
good way to access the static and the dynamic context: using Spoon=20
template parameters so that:
- the way to access static info is consistent with the way of accessing=20
dynamic info (and is pure Java)
- the joinpoint's dynamic context is accessed directly (because aspects=20
are inlined)

>=20
> - The logging example doesn't seem to be aspect-oriented at all, becaus=
e=20
> the join points in the base code have to be annotated explicitly.=20
> ("Aspect, go here!", so to speak! ;) This seems to contradict the=20
> otherwise common idea that base code should be oblivious to the aspects=
=20
> that are applied. Am I missing something?

Arrrrggllll! I am NOT going to have this discussion again with you! :)

Annotations can be seen as a way to define a pointcut manually. Tool=20
support (like AspectJ's pointcuts) can help you to define it in an=20
automatic way.

So, I'd call Spoon-AOP a manual AOP approach (annotation-driven), but I=20
do not think you can say that it is "not aspect-oriented at all".

This said, I am currently developing a simple way to define oblivious=20
aspects in Spoon-AOP. You would not believe how simple it is. For=20
instance, if you take the Logging example I show at=20
http://www.lifl.fr/~pawlak/spoon-aop/, you can also write it this way:

public LoggingAspect extends Aspect {
    // @Log <-- removed
    @Before
    void doLog() { System.out.println("calling "+_executableName_); }
}

Then, the doLog advice will apply to all the methods, even when not=20
tagged (except methods defined in the same aspect). Of course, you will=20
be able to filter where the aspect applies.

public LoggingAspect extends Aspect {
    // to log all the methods that start with "set"
    @Before
    void doLog() {
      if(_executableName_.startsWith("set"))
        System.out.println("calling "+_executableName_);
    }
}

My partial evaluator still needs some work to be able to do this, but I=20
really think it will work soon.

And this is my last word.

Really. :)

Cheers,
/Renaud


>=20
> The way you use annotations here looks more like you would also use a=20
> macro facility. See also=20
> http://www.sdmagazine.com/documents/s=3D8993/sdm0405h/
>=20
>=20
> Pascal
>=20
>=20
> On 1 Feb 2006, at 12:23, Renaud Pawlak wrote:
>=20
>>
>> Ok,
>>
>> For those how are interested, I've updated the Spoon-AOP home page wit=
h
>> what we said here and with some more analysis and performance figures.=
 I
>> have also added the examples in the Spoon CVS.
>>
>> http://www.lifl.fr/~pawlak/spoon-aop/
>>
>> Best regards,
>> /Renaud
>>
>>
>> Adrian Colyer wrote:
>>> My last post on the subject, and then we should let folks investigate
>>> the good stuff that Spoon offers as you say.
>>>
>>>> Really? Well, I took this example exactly because in AspectJ, you
>>>> cannot access the number of parameters as static information. In
>>>> Spoon-AOP you can. So I can write an advice that says:
>>>>
>>>> if(_argumentCount_=3D=3D0) { do_0 }
>>>> if(_argumentCount_=3D=3D1) { do_1 }
>>>> if(_argumentCount_>=3D2) { do_gte_2 }
>>>>
>>>> And there will be no overhead.
>>>
>>>
>>> You /can/ access the number of parameters as static information using
>>> thisJoinPointStaticPart.getSignature(), but it's not as succint as in
>>> Spoon-AOP:
>>>
>>> int getNumParameters(JoinPoint.StaticPart tjpsp) {
>>>   Signature sig =3D tjpsp.getSignature();
>>>   if (sig instanceof CodeSignature) {
>>>     return ((CodeSignature)sig).getParameterTypes().length;
>>>   } else {
>>>     return 0;
>>>   }
>>> }
>>>
>>> if we had lots of people asking for easy static access to the number =
of
>>> parameters, we could obviously simplify that, but no-one's ever asked=
=20
>>> afaik!
>>>
>>> If I needed to implement your example in AspectJ, I'd probably do thi=
s:
>>>
>>> before() : args() {
>>>   do_0();
>>> }
>>>
>>> before() : args(*) {
>>>   do_1();
>>> }
>>>
>>> before() : args(*,*,..) {
>>>   do_gte_2();
>>> }
>>>
>>> but I've also never yet needed to write advice that was conditional o=
n
>>> the number of parameters and didn't need access to the parameter=20
>>> values...
>>>
>>> Eric described the approach that AspectJ takes to JoinPoint informati=
on
>>> in his post - we build it statically in generated code as this perfor=
ms
>>> better than runtime generation using reflection.
>>>
>>> Regards, Adrian.
>>>
>>> Renaud Pawlak wrote:
>>>
>>>> Hi Adrian,
>>>>
>>>> As I said on the Spoon-AOP page, this is on-going work and I need to
>>>> investigate and explain more what it does exactly. For the moment, i=
t
>>>> may seem a little bit "magic" when you do not know about Spoon
>>>> templates and I am sorry about this. I will complete and explain
>>>> better when my time will allow me.
>>>>
>>>> However, I would like to explain myself a little bit better in this
>>>> email and answer some of your questions.
>>>>
>>>>> into spoon itself yet). Your comment on the AspectJ performance is =
a
>>>>> little misleading.
>>>>
>>>> I am sorry about this, but it is hard to cover all the details of
>>>> things when you want to make a clear point. Here, the code I show
>>>> gives the results I put in my table. Anybody can try it and get the
>>>> same results. I am perfectly aware that this example is a little bit
>>>> biased (like most performance figures), but that's to make my point.
>>>>
>>>>> AspectJ will optimize any use of thisJoinPoint that uses only the
>>>>> "thisJoinPointStaticPart" of the JoinPoint interface.
>>>>> "thisJoinPoint.getArgs()" falls out of that contract, because it
>>>>> returns the actual argument array. The statically knowable subset o=
f
>>>>> join point information can be no different between Spoon-AOP and
>>>>> AspectJ (or any other Java-based AOP implementation).
>>>>
>>>> Really? Well, I took this example exactly because in AspectJ, you
>>>> cannot access the number of parameters as static information. In
>>>> Spoon-AOP you can. So I can write an advice that says:
>>>>
>>>> if(_argumentCount_=3D=3D0) { do_0 }
>>>> if(_argumentCount_=3D=3D1) { do_1 }
>>>> if(_argumentCount_>=3D2) { do_gte_2 }
>>>>
>>>> And there will be no overhead.
>>>>
>>>> Even better, if the number of arguments is 1 for a given joinpoint,
>>>> the woven code will be exactly (partial evaluation):
>>>>
>>>> do_1
>>>>
>>>> If you want to know all the information that Spoon-AOP can staticall=
y
>>>> access, you can refer to the template parameters defined in the Aspe=
ct
>>>> class:=20
>>>> http://www.lifl.fr/~pawlak/spoon-aop/javadoc/spoon/aop/Aspect.html
>>>>
>>>> Anyway, in addition to these statically known info about the
>>>> joinpoint, Spoon-AOP is open by using compile-time reflection,
>>>> similarly to Josh:
>>>> http://www.csg.is.titech.ac.jp/paper/chiba-aosd2004.pdf
>>>>
>>>> It means that any aspect can define new static info by introspecting=
 a
>>>> Java metamodel provided by Spoon at compile time. For example, let's
>>>> say I want to add an information that tells me if a method uses a
>>>> field f, well I can do it with Spoon-AOP (and use it in my advice wi=
th
>>>> no runtime overhead)!
>>>>
>>>>> In AspectJ you can:
>>>>>
>>>>> * implement the example much more efficiently using a pointcut:
>>>>> before() : execution(* ToBeAdvised.*(*,..)) { ... }
>>>>
>>>> I have never seen that before. Does it mean that you capture all the
>>>> methods that have more than zero arguments? Well, in that case, I ha=
ve
>>>> to say two things:
>>>>
>>>> - if you want to implement my example, you have to write two pieces =
of
>>>> advice (one for the case argCount is 0 and one otherwise). I don't
>>>> think that it is very nice or readable.
>>>> - what if you want to do something special in case there are 3
>>>> arguments (for instance)?
>>>>
>>>>> * in general, bind the contextual information you need explicitly,
>>>>> giving you typed advice and no overhead
>>>>
>>>> Yep, but it will also give you less reusable advice code and pointcu=
ts
>>>> (LESS reusable aspects in general). Sometimes, you want to perform
>>>> GENERIC actions, with minimal information, but with no overhead. It =
is
>>>> most of the time not possible with AspectJ.
>>>>
>>>>> * use thisJoinPointStaticPart (or the static parts of thisJoinPoint=
,
>>>>> which will be optimised to give the same result)
>>>>
>>>> I'd like too, but sometimes I'd like not.
>>>>
>>>>> * only use the full thisJoinPoint object when you really need runti=
me
>>>>> access to the actual this, target, and args objects (and then there
>>>>> are lazyTjp optimizations that will also kick in)
>>>>
>>>> I don't know about this. Is it some kind of partial evaluation? Spoo=
n
>>>> already support partial evaluation during the weaving process. That'=
s
>>>> why it is so fast in my example, without requiring any special JVM
>>>> enhancements.
>>>>
>>>>> The JoinPoint implementation is also not based on java.lang.reflect
>>>>> under the covers (you state otherwise).
>>>>
>>>> Ooops! I will change it, but I would be very interested in knowing
>>>> exactly how it is done then, because I lack time to dive into Aspect=
J
>>>> sources... Note that java.lang.reflect is very optimized nowadays an=
d
>>>> that's why I assumed that it was use here. I'm surprised.
>>>>
>>>>> In what way do you believe Spoon-AOP is "better typed" than most of
>>>>> the classical AOP approaches? Can you give an example where Spoon-A=
OP
>>>>> has stronger typing than an equivalent AspectJ program?
>>>>
>>>> Well, I never said that Spoon-AOP was better-typed that AspectJ.
>>>> Actually, as far as I can tell it is just as well typed.
>>>>
>>>> But, what is interesting here, is that Spoon-AOP is not a new
>>>> language, but a pure Java framework that uses CT-reflection to exten=
ds
>>>> the Java's semantics. So, compared to the framework approaches (JAC,
>>>> JBoss-AOP, Spring...), Spoon-AOP is much better typed.
>>>>
>>>> Also, I think that Spoon-AOP is easier to use than AspectJ for a
>>>> similar type safetyness and better performances.
>>>>
>>>> For instance, with AspectJ, you have to bind the parameters you use
>>>> when you want type safety and performance. With Spoon-AOP, you can d=
o
>>>> it in several ways. For instance to advise this method:
>>>>
>>>> @A
>>>> void m(int i, String s) { ... }
>>>>
>>>> You can write this advice:
>>>>
>>>> @A @Before
>>>> void a(int i,String s) {
>>>>   System.out.println("args=3D"+i+","+s);
>>>> }
>>>>
>>>> This is kind of similar to AspectJ where you have to bind the
>>>> parameters explicitly... BUT it is not reusable. Indeed, it is
>>>> efficient but it does not work for any number of parameters. A more
>>>> reusable way of doing it in Spoon-AOP, would be:
>>>>
>>>> @A @Before
>>>> void a() {
>>>>   System.out.print("args=3D");
>>>>   if(_argumentCount_>=3D1)
>>>>     System.out.print(","+_arguments_[0]);
>>>>   if(_argumentCount_>=3D2)
>>>>     System.out.print(","+_arguments_[1]);
>>>>   if(_argumentCount_>=3D3)
>>>>     System.out.print(","+_arguments_[2]);
>>>>   System.out.println();
>>>> }
>>>>
>>>> These look like untyped argument accesses, but actually they are not.
>>>> Indeed _arguments_ does not represent the runtime arguments, but **t=
he
>>>> compile-time argument accesses**. Then, the compilation phase for th=
e
>>>> woven code will perform the type checking. For instance, with the
>>>> method m(int i, String s), the woven code will be (after partial
>>>> evaluation):
>>>>
>>>> void m(int i, String s) {
>>>>   System.out.print("args=3D");
>>>>   System.out.print(","+i);
>>>>   System.out.print(","+s);
>>>>   System.out.println();
>>>>   ... // original m code
>>>> }
>>>>
>>>> ..., which is more efficient than a reflective version...
>>>>
>>>> (Note that I could also make a foreach loop (finite loop), but my
>>>> partial evaluator does not know how to deal with these yet.)
>>>>
>>>> Whatever, I feel like I said too much already and that nobody will
>>>> read this. Once again, this is ongoing work and I am sure that there
>>>> are still a lot of defects. Also, it will be hard to defend it by
>>>> myself if nobody comes and see what it does exactly... So I'd like t=
o
>>>> encourage anybody that would have some extra time to try it and to
>>>> report on it :)
>>>>
>>>> Cheers,
>>>> /Renaud
>>>>
>>>>> Renaud Pawlak wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> It is my pleasure to announce here the first release of Spoon: a
>>>>>> powerful Java 5 annotation processing tool.
>>>>>>
>>>>>> It is available in Open Source at http://spoon.gforge.inria.fr/
>>>>>>
>>>>>> Spoon is similar to APT
>>>>>> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html=
)
>>>>>> except that it provides a full metamodel of Java 5 (also models th=
e
>>>>>> Java code in the method bodies) and that it implements compile-tim=
e
>>>>>> reflection. So, Spoon can be used for more in-depth and fine-grain=
ed
>>>>>> program transformation and analysis.
>>>>>>
>>>>>> In addition, for specifying the transformations, Spoon allows the
>>>>>> use of pure-Java templates (which can be compared to Velocity
>>>>>> templates except that they are written in Java and, as such,
>>>>>> directly benefit the IDE support for type soundness, navigation, a=
nd
>>>>>> other features).
>>>>>>
>>>>>> Finally, let me point out for you a small application of Spoon: an
>>>>>> original and efficient annotation-driven AOP weaver called
>>>>>> "Spoon-AOP" available at http://www.lifl.fr/~pawlak/spoon-aop/
>>>>>>
>>>>>> Enjoy!
>>>>>> /Renaud
>>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________
>>>>> AOSD Discuss mailing list    -    di...@ao...
>>>>> To unsubscribe go to http://aosd.net
>>>>>
>>>>> Check out the AOSD.net Wiki: http://aosd.net/wiki
>>>>>
>>>>
>>>
>>>
>>>
>>> __________________________________________________
>>> AOSD Discuss mailing list    -    di...@ao...
>>> To unsubscribe go to http://aosd.net
>>>
>>> Check out the AOSD.net Wiki: http://aosd.net/wiki
>>>
>>
>>
>> --Renaud Pawlak
>> Researcher
>> INRIA Futurs - Projet JACQUARD
>> LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
>> 59655 Villeneuve d'Ascq C=E9dex - FRANCE
>> Phone:  (+33) 3 28 77 85 79
>> Cell:   (+33) 6 62 00 19 19
>> Fax:    (+33) 3 28 77 85 37
>> Emails: ren...@in... / pa...@li...
>> WWW:    http://www.lifl.fr/~pawlak
>>
>> __________________________________________________
>> AOSD Discuss mailing list    -    di...@ao...
>> To unsubscribe go to http://aosd.net
>>
>> Check out the AOSD.net Wiki: http://aosd.net/wiki
>>
>=20
> --Pascal Costanza, mailto:pc...@p-..., http://p-cos.net
> Vrije Universiteit Brussel, Programming Technology Lab
> Pleinlaan 2, B-1050 Brussel, Belgium
>=20
>=20
>=20
>=20


--=20
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone:  (+33) 3 28 77 85 79
Cell:   (+33) 6 62 00 19 19
Fax:    (+33) 3 28 77 85 37
Emails: ren...@in... / pa...@li...
WWW:    http://www.lifl.fr/~pawlak

Ok,

For those how are interested, I've updated the Spoon-AOP home page with=20
what we said here and with some more analysis and performance figures. I=20
have also added the examples in the Spoon CVS.

http://www.lifl.fr/~pawlak/spoon-aop/

Best regards,
/Renaud


Adrian Colyer wrote:
> My last post on the subject, and then we should let folks investigate=20
> the good stuff that Spoon offers as you say.
>=20
>> Really? Well, I took this example exactly because in AspectJ, you=20
>> cannot access the number of parameters as static information. In=20
>> Spoon-AOP you can. So I can write an advice that says:
>>
>> if(_argumentCount_=3D=3D0) { do_0 }
>> if(_argumentCount_=3D=3D1) { do_1 }
>> if(_argumentCount_>=3D2) { do_gte_2 }
>>
>> And there will be no overhead.=20
>=20
>=20
> You /can/ access the number of parameters as static information using=20
> thisJoinPointStaticPart.getSignature(), but it's not as succint as in=20
> Spoon-AOP:
>=20
> int getNumParameters(JoinPoint.StaticPart tjpsp) {
>   Signature sig =3D tjpsp.getSignature();
>   if (sig instanceof CodeSignature) {
>     return ((CodeSignature)sig).getParameterTypes().length;
>   } else {
>     return 0;
>   }
> }
>=20
> if we had lots of people asking for easy static access to the number of=
=20
> parameters, we could obviously simplify that, but no-one's ever asked a=
faik!
>=20
> If I needed to implement your example in AspectJ, I'd probably do this:
>=20
> before() : args() {
>   do_0();
> }
>=20
> before() : args(*) {
>   do_1();
> }
>=20
> before() : args(*,*,..) {
>   do_gte_2();
> }
>=20
> but I've also never yet needed to write advice that was conditional on=20
> the number of parameters and didn't need access to the parameter values=
...
>=20
> Eric described the approach that AspectJ takes to JoinPoint information=
=20
> in his post - we build it statically in generated code as this performs=
=20
> better than runtime generation using reflection.
>=20
> Regards, Adrian.
>=20
> Renaud Pawlak wrote:
>=20
>> Hi Adrian,
>>
>> As I said on the Spoon-AOP page, this is on-going work and I need to=20
>> investigate and explain more what it does exactly. For the moment, it=20
>> may seem a little bit "magic" when you do not know about Spoon=20
>> templates and I am sorry about this. I will complete and explain=20
>> better when my time will allow me.
>>
>> However, I would like to explain myself a little bit better in this=20
>> email and answer some of your questions.
>>
>>> into spoon itself yet). Your comment on the AspectJ performance is a=20
>>> little misleading.=20
>>
>> I am sorry about this, but it is hard to cover all the details of=20
>> things when you want to make a clear point. Here, the code I show=20
>> gives the results I put in my table. Anybody can try it and get the=20
>> same results. I am perfectly aware that this example is a little bit=20
>> biased (like most performance figures), but that's to make my point.
>>
>>> AspectJ will optimize any use of thisJoinPoint that uses only the=20
>>> "thisJoinPointStaticPart" of the JoinPoint interface.=20
>>> "thisJoinPoint.getArgs()" falls out of that contract, because it=20
>>> returns the actual argument array. The statically knowable subset of=20
>>> join point information can be no different between Spoon-AOP and=20
>>> AspectJ (or any other Java-based AOP implementation).
>>
>> Really? Well, I took this example exactly because in AspectJ, you=20
>> cannot access the number of parameters as static information. In=20
>> Spoon-AOP you can. So I can write an advice that says:
>>
>> if(_argumentCount_=3D=3D0) { do_0 }
>> if(_argumentCount_=3D=3D1) { do_1 }
>> if(_argumentCount_>=3D2) { do_gte_2 }
>>
>> And there will be no overhead.
>>
>> Even better, if the number of arguments is 1 for a given joinpoint,=20
>> the woven code will be exactly (partial evaluation):
>>
>> do_1
>>
>> If you want to know all the information that Spoon-AOP can statically=20
>> access, you can refer to the template parameters defined in the Aspect=
=20
>> class: http://www.lifl.fr/~pawlak/spoon-aop/javadoc/spoon/aop/Aspect.h=
tml
>>
>> Anyway, in addition to these statically known info about the=20
>> joinpoint, Spoon-AOP is open by using compile-time reflection,=20
>> similarly to Josh:=20
>> http://www.csg.is.titech.ac.jp/paper/chiba-aosd2004.pdf
>>
>> It means that any aspect can define new static info by introspecting a=
=20
>> Java metamodel provided by Spoon at compile time. For example, let's=20
>> say I want to add an information that tells me if a method uses a=20
>> field f, well I can do it with Spoon-AOP (and use it in my advice with=
=20
>> no runtime overhead)!
>>
>>> In AspectJ you can:
>>>
>>> * implement the example much more efficiently using a pointcut: =20
>>> before() : execution(* ToBeAdvised.*(*,..)) { ... }
>>
>> I have never seen that before. Does it mean that you capture all the=20
>> methods that have more than zero arguments? Well, in that case, I have=
=20
>> to say two things:
>>
>> - if you want to implement my example, you have to write two pieces of=
=20
>> advice (one for the case argCount is 0 and one otherwise). I don't=20
>> think that it is very nice or readable.
>> - what if you want to do something special in case there are 3=20
>> arguments (for instance)?
>>
>>> * in general, bind the contextual information you need explicitly,=20
>>> giving you typed advice and no overhead
>>
>> Yep, but it will also give you less reusable advice code and pointcuts=
=20
>> (LESS reusable aspects in general). Sometimes, you want to perform=20
>> GENERIC actions, with minimal information, but with no overhead. It is=
=20
>> most of the time not possible with AspectJ.
>>
>>> * use thisJoinPointStaticPart (or the static parts of thisJoinPoint,=20
>>> which will be optimised to give the same result)
>>
>> I'd like too, but sometimes I'd like not.
>>
>>> * only use the full thisJoinPoint object when you really need runtime=
=20
>>> access to the actual this, target, and args objects (and then there=20
>>> are lazyTjp optimizations that will also kick in)
>>
>> I don't know about this. Is it some kind of partial evaluation? Spoon=20
>> already support partial evaluation during the weaving process. That's=20
>> why it is so fast in my example, without requiring any special JVM=20
>> enhancements.
>>
>>> The JoinPoint implementation is also not based on java.lang.reflect=20
>>> under the covers (you state otherwise).
>>
>> Ooops! I will change it, but I would be very interested in knowing=20
>> exactly how it is done then, because I lack time to dive into AspectJ=20
>> sources... Note that java.lang.reflect is very optimized nowadays and=20
>> that's why I assumed that it was use here. I'm surprised.
>>
>>> In what way do you believe Spoon-AOP is "better typed" than most of=20
>>> the classical AOP approaches? Can you give an example where Spoon-AOP=
=20
>>> has stronger typing than an equivalent AspectJ program?
>>
>> Well, I never said that Spoon-AOP was better-typed that AspectJ.=20
>> Actually, as far as I can tell it is just as well typed.
>>
>> But, what is interesting here, is that Spoon-AOP is not a new=20
>> language, but a pure Java framework that uses CT-reflection to extends=
=20
>> the Java's semantics. So, compared to the framework approaches (JAC,=20
>> JBoss-AOP, Spring...), Spoon-AOP is much better typed.
>>
>> Also, I think that Spoon-AOP is easier to use than AspectJ for a=20
>> similar type safetyness and better performances.
>>
>> For instance, with AspectJ, you have to bind the parameters you use=20
>> when you want type safety and performance. With Spoon-AOP, you can do=20
>> it in several ways. For instance to advise this method:
>>
>> @A
>> void m(int i, String s) { ... }
>>
>> You can write this advice:
>>
>> @A @Before
>> void a(int i,String s) {
>>   System.out.println("args=3D"+i+","+s);
>> }
>>
>> This is kind of similar to AspectJ where you have to bind the=20
>> parameters explicitly... BUT it is not reusable. Indeed, it is=20
>> efficient but it does not work for any number of parameters. A more=20
>> reusable way of doing it in Spoon-AOP, would be:
>>
>> @A @Before
>> void a() {
>>   System.out.print("args=3D");
>>   if(_argumentCount_>=3D1)
>>     System.out.print(","+_arguments_[0]);
>>   if(_argumentCount_>=3D2)
>>     System.out.print(","+_arguments_[1]);
>>   if(_argumentCount_>=3D3)
>>     System.out.print(","+_arguments_[2]);
>>   System.out.println();
>> }
>>
>> These look like untyped argument accesses, but actually they are not.=20
>> Indeed _arguments_ does not represent the runtime arguments, but **the=
=20
>> compile-time argument accesses**. Then, the compilation phase for the=20
>> woven code will perform the type checking. For instance, with the=20
>> method m(int i, String s), the woven code will be (after partial=20
>> evaluation):
>>
>> void m(int i, String s) {
>>   System.out.print("args=3D");
>>   System.out.print(","+i);
>>   System.out.print(","+s);
>>   System.out.println();
>>   ... // original m code
>> }
>>
>> ..., which is more efficient than a reflective version...
>>
>> (Note that I could also make a foreach loop (finite loop), but my=20
>> partial evaluator does not know how to deal with these yet.)
>>
>> Whatever, I feel like I said too much already and that nobody will=20
>> read this. Once again, this is ongoing work and I am sure that there=20
>> are still a lot of defects. Also, it will be hard to defend it by=20
>> myself if nobody comes and see what it does exactly... So I'd like to=20
>> encourage anybody that would have some extra time to try it and to=20
>> report on it :)
>>
>> Cheers,
>> /Renaud
>>
>>> Renaud Pawlak wrote:
>>>
>>>> Dear all,
>>>>
>>>> It is my pleasure to announce here the first release of Spoon: a=20
>>>> powerful Java 5 annotation processing tool.
>>>>
>>>> It is available in Open Source at http://spoon.gforge.inria.fr/
>>>>
>>>> Spoon is similar to APT=20
>>>> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html)=20
>>>> except that it provides a full metamodel of Java 5 (also models the=20
>>>> Java code in the method bodies) and that it implements compile-time=20
>>>> reflection. So, Spoon can be used for more in-depth and fine-grained=
=20
>>>> program transformation and analysis.
>>>>
>>>> In addition, for specifying the transformations, Spoon allows the=20
>>>> use of pure-Java templates (which can be compared to Velocity=20
>>>> templates except that they are written in Java and, as such,=20
>>>> directly benefit the IDE support for type soundness, navigation, and=
=20
>>>> other features).
>>>>
>>>> Finally, let me point out for you a small application of Spoon: an=20
>>>> original and efficient annotation-driven AOP weaver called=20
>>>> "Spoon-AOP" available at http://www.lifl.fr/~pawlak/spoon-aop/
>>>>
>>>> Enjoy!
>>>> /Renaud
>>>>
>>>
>>>
>>> __________________________________________________
>>> AOSD Discuss mailing list    -    di...@ao...
>>> To unsubscribe go to http://aosd.net
>>>
>>> Check out the AOSD.net Wiki: http://aosd.net/wiki
>>>
>>
>=20
>=20
>=20
> __________________________________________________
> AOSD Discuss mailing list    -    di...@ao...
> To unsubscribe go to http://aosd.net
>=20
> Check out the AOSD.net Wiki: http://aosd.net/wiki
>=20


--=20
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone:  (+33) 3 28 77 85 79
Cell:   (+33) 6 62 00 19 19
Fax:    (+33) 3 28 77 85 37
Emails: ren...@in... / pa...@li...
WWW:    http://www.lifl.fr/~pawlak

Adrian Colyer wrote:
> My last post on the subject, and then we should let folks investigate=20
> the good stuff that Spoon offers as you say.

That's indeed very wise. This will be my last post too. Very short.

> You /can/ access the number of parameters as static information using=20
> thisJoinPointStaticPart.getSignature(), but it's not as succint as in=20
> Spoon-AOP:

Umm, it seems that I did not know the AspectJ API well enough to do=20
this. Thanks a lot for clarifying!

> If I needed to implement your example in AspectJ, I'd probably do this:
>=20
> before() : args() {
>  do_0();
> }
>=20
> before() : args(*) {
>  do_1();
> }
>=20
> before() : args(*,*,..) {
>  do_gte_2();
> }
>=20
> but I've also never yet needed to write advice that was conditional on=20
> the number of parameters and didn't need access to the parameter values=
...

Yes... And then you would have to access the dynamic part again :(

>=20
> Eric described the approach that AspectJ takes to JoinPoint information=
=20
> in his post - we build it statically in generated code as this performs=
=20
> better than runtime generation using reflection.

Yes, I see that. Thanks also for the precision. According to my=20
experience in non-typed AOP, the main overhead is the creation of the=20
array of parameters at runtime. This is why the call to getArguments()=20
makes it so slow.

I'll shut up now. Thanks again for discussing with me. I'll update the=20
Spoon-AOP page with some useful info.

/Renaud

>=20
> Regards, Adrian.
>=20
> Renaud Pawlak wrote:
>=20
>>
>> Hi Adrian,
>>
>> As I said on the Spoon-AOP page, this is on-going work and I need to=20
>> investigate and explain more what it does exactly. For the moment, it=20
>> may seem a little bit "magic" when you do not know about Spoon=20
>> templates and I am sorry about this. I will complete and explain=20
>> better when my time will allow me.
>>
>> However, I would like to explain myself a little bit better in this=20
>> email and answer some of your questions.
>>
>>> into spoon itself yet). Your comment on the AspectJ performance is a=20
>>> little misleading.=20
>>
>>
>> I am sorry about this, but it is hard to cover all the details of=20
>> things when you want to make a clear point. Here, the code I show=20
>> gives the results I put in my table. Anybody can try it and get the=20
>> same results. I am perfectly aware that this example is a little bit=20
>> biased (like most performance figures), but that's to make my point.
>>
>>> AspectJ will optimize any use of thisJoinPoint that uses only the=20
>>> "thisJoinPointStaticPart" of the JoinPoint interface.=20
>>> "thisJoinPoint.getArgs()" falls out of that contract, because it=20
>>> returns the actual argument array. The statically knowable subset of=20
>>> join point information can be no different between Spoon-AOP and=20
>>> AspectJ (or any other Java-based AOP implementation).
>>
>>
>> Really? Well, I took this example exactly because in AspectJ, you=20
>> cannot access the number of parameters as static information. In=20
>> Spoon-AOP you can. So I can write an advice that says:
>>
>> if(_argumentCount_=3D=3D0) { do_0 }
>> if(_argumentCount_=3D=3D1) { do_1 }
>> if(_argumentCount_>=3D2) { do_gte_2 }
>>
>> And there will be no overhead.
>>
>> Even better, if the number of arguments is 1 for a given joinpoint,=20
>> the woven code will be exactly (partial evaluation):
>>
>> do_1
>>
>> If you want to know all the information that Spoon-AOP can statically=20
>> access, you can refer to the template parameters defined in the Aspect=
=20
>> class: http://www.lifl.fr/~pawlak/spoon-aop/javadoc/spoon/aop/Aspect.h=
tml
>>
>> Anyway, in addition to these statically known info about the=20
>> joinpoint, Spoon-AOP is open by using compile-time reflection,=20
>> similarly to Josh:=20
>> http://www.csg.is.titech.ac.jp/paper/chiba-aosd2004.pdf
>>
>> It means that any aspect can define new static info by introspecting a=
=20
>> Java metamodel provided by Spoon at compile time. For example, let's=20
>> say I want to add an information that tells me if a method uses a=20
>> field f, well I can do it with Spoon-AOP (and use it in my advice with=
=20
>> no runtime overhead)!
>>
>>>
>>> In AspectJ you can:
>>>
>>> * implement the example much more efficiently using a pointcut: =20
>>> before() : execution(* ToBeAdvised.*(*,..)) { ... }
>>
>>
>> I have never seen that before. Does it mean that you capture all the=20
>> methods that have more than zero arguments? Well, in that case, I have=
=20
>> to say two things:
>>
>> - if you want to implement my example, you have to write two pieces of=
=20
>> advice (one for the case argCount is 0 and one otherwise). I don't=20
>> think that it is very nice or readable.
>> - what if you want to do something special in case there are 3=20
>> arguments (for instance)?
>>
>>> * in general, bind the contextual information you need explicitly,=20
>>> giving you typed advice and no overhead
>>
>>
>> Yep, but it will also give you less reusable advice code and pointcuts=
=20
>> (LESS reusable aspects in general). Sometimes, you want to perform=20
>> GENERIC actions, with minimal information, but with no overhead. It is=
=20
>> most of the time not possible with AspectJ.
>>
>>> * use thisJoinPointStaticPart (or the static parts of thisJoinPoint,=20
>>> which will be optimised to give the same result)
>>
>>
>> I'd like too, but sometimes I'd like not.
>>
>>> * only use the full thisJoinPoint object when you really need runtime=
=20
>>> access to the actual this, target, and args objects (and then there=20
>>> are lazyTjp optimizations that will also kick in)
>>
>>
>> I don't know about this. Is it some kind of partial evaluation? Spoon=20
>> already support partial evaluation during the weaving process. That's=20
>> why it is so fast in my example, without requiring any special JVM=20
>> enhancements.
>>
>>>
>>> The JoinPoint implementation is also not based on java.lang.reflect=20
>>> under the covers (you state otherwise).
>>
>>
>> Ooops! I will change it, but I would be very interested in knowing=20
>> exactly how it is done then, because I lack time to dive into AspectJ=20
>> sources... Note that java.lang.reflect is very optimized nowadays and=20
>> that's why I assumed that it was use here. I'm surprised.
>>
>>>
>>> In what way do you believe Spoon-AOP is "better typed" than most of=20
>>> the classical AOP approaches? Can you give an example where Spoon-AOP=
=20
>>> has stronger typing than an equivalent AspectJ program?
>>
>>
>> Well, I never said that Spoon-AOP was better-typed that AspectJ.=20
>> Actually, as far as I can tell it is just as well typed.
>>
>> But, what is interesting here, is that Spoon-AOP is not a new=20
>> language, but a pure Java framework that uses CT-reflection to extends=
=20
>> the Java's semantics. So, compared to the framework approaches (JAC,=20
>> JBoss-AOP, Spring...), Spoon-AOP is much better typed.
>>
>> Also, I think that Spoon-AOP is easier to use than AspectJ for a=20
>> similar type safetyness and better performances.
>>
>> For instance, with AspectJ, you have to bind the parameters you use=20
>> when you want type safety and performance. With Spoon-AOP, you can do=20
>> it in several ways. For instance to advise this method:
>>
>> @A
>> void m(int i, String s) { ... }
>>
>> You can write this advice:
>>
>> @A @Before
>> void a(int i,String s) {
>>   System.out.println("args=3D"+i+","+s);
>> }
>>
>> This is kind of similar to AspectJ where you have to bind the=20
>> parameters explicitly... BUT it is not reusable. Indeed, it is=20
>> efficient but it does not work for any number of parameters. A more=20
>> reusable way of doing it in Spoon-AOP, would be:
>>
>> @A @Before
>> void a() {
>>   System.out.print("args=3D");
>>   if(_argumentCount_>=3D1)
>>     System.out.print(","+_arguments_[0]);
>>   if(_argumentCount_>=3D2)
>>     System.out.print(","+_arguments_[1]);
>>   if(_argumentCount_>=3D3)
>>     System.out.print(","+_arguments_[2]);
>>   System.out.println();
>> }
>>
>> These look like untyped argument accesses, but actually they are not.=20
>> Indeed _arguments_ does not represent the runtime arguments, but **the=
=20
>> compile-time argument accesses**. Then, the compilation phase for the=20
>> woven code will perform the type checking. For instance, with the=20
>> method m(int i, String s), the woven code will be (after partial=20
>> evaluation):
>>
>> void m(int i, String s) {
>>   System.out.print("args=3D");
>>   System.out.print(","+i);
>>   System.out.print(","+s);
>>   System.out.println();
>>   ... // original m code
>> }
>>
>> ..., which is more efficient than a reflective version...
>>
>> (Note that I could also make a foreach loop (finite loop), but my=20
>> partial evaluator does not know how to deal with these yet.)
>>
>> Whatever, I feel like I said too much already and that nobody will=20
>> read this. Once again, this is ongoing work and I am sure that there=20
>> are still a lot of defects. Also, it will be hard to defend it by=20
>> myself if nobody comes and see what it does exactly... So I'd like to=20
>> encourage anybody that would have some extra time to try it and to=20
>> report on it :)
>>
>> Cheers,
>> /Renaud
>>
>>>
>>> Renaud Pawlak wrote:
>>>
>>>> Dear all,
>>>>
>>>> It is my pleasure to announce here the first release of Spoon: a=20
>>>> powerful Java 5 annotation processing tool.
>>>>
>>>> It is available in Open Source at http://spoon.gforge.inria.fr/
>>>>
>>>> Spoon is similar to APT=20
>>>> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html)=20
>>>> except that it provides a full metamodel of Java 5 (also models the=20
>>>> Java code in the method bodies) and that it implements compile-time=20
>>>> reflection. So, Spoon can be used for more in-depth and fine-grained=
=20
>>>> program transformation and analysis.
>>>>
>>>> In addition, for specifying the transformations, Spoon allows the=20
>>>> use of pure-Java templates (which can be compared to Velocity=20
>>>> templates except that they are written in Java and, as such,=20
>>>> directly benefit the IDE support for type soundness, navigation, and=
=20
>>>> other features).
>>>>
>>>> Finally, let me point out for you a small application of Spoon: an=20
>>>> original and efficient annotation-driven AOP weaver called=20
>>>> "Spoon-AOP" available at http://www.lifl.fr/~pawlak/spoon-aop/
>>>>
>>>> Enjoy!
>>>> /Renaud
>>>>
>>>
>>>
>>>
>>> __________________________________________________
>>> AOSD Discuss mailing list    -    di...@ao...
>>> To unsubscribe go to http://aosd.net
>>>
>>> Check out the AOSD.net Wiki: http://aosd.net/wiki
>>>
>>
>>
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log=20
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>=20


--=20
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone:  (+33) 3 28 77 85 79
Cell:   (+33) 6 62 00 19 19
Fax:    (+33) 3 28 77 85 37
Emails: ren...@in... / pa...@li...
WWW:    http://www.lifl.fr/~pawlak

My last post on the subject, and then we should let folks investigate 
the good stuff that Spoon offers as you say.

> Really? Well, I took this example exactly because in AspectJ, you 
> cannot access the number of parameters as static information. In 
> Spoon-AOP you can. So I can write an advice that says:
>
> if(_argumentCount_==0) { do_0 }
> if(_argumentCount_==1) { do_1 }
> if(_argumentCount_>=2) { do_gte_2 }
>
> And there will be no overhead. 


You /can/ access the number of parameters as static information using 
thisJoinPointStaticPart.getSignature(), but it's not as succint as in 
Spoon-AOP:

int getNumParameters(JoinPoint.StaticPart tjpsp) {
  Signature sig = tjpsp.getSignature();
  if (sig instanceof CodeSignature) {
    return ((CodeSignature)sig).getParameterTypes().length;
  } else {
    return 0;
  }
}

if we had lots of people asking for easy static access to the number of 
parameters, we could obviously simplify that, but no-one's ever asked afaik!

If I needed to implement your example in AspectJ, I'd probably do this:

before() : args() {
  do_0();
}

before() : args(*) {
  do_1();
}

before() : args(*,*,..) {
  do_gte_2();
}

but I've also never yet needed to write advice that was conditional on 
the number of parameters and didn't need access to the parameter values...

Eric described the approach that AspectJ takes to JoinPoint information 
in his post - we build it statically in generated code as this performs 
better than runtime generation using reflection.

Regards, Adrian.

Renaud Pawlak wrote:

>
> Hi Adrian,
>
> As I said on the Spoon-AOP page, this is on-going work and I need to 
> investigate and explain more what it does exactly. For the moment, it 
> may seem a little bit "magic" when you do not know about Spoon 
> templates and I am sorry about this. I will complete and explain 
> better when my time will allow me.
>
> However, I would like to explain myself a little bit better in this 
> email and answer some of your questions.
>
>> into spoon itself yet). Your comment on the AspectJ performance is a 
>> little misleading. 
>
>
> I am sorry about this, but it is hard to cover all the details of 
> things when you want to make a clear point. Here, the code I show 
> gives the results I put in my table. Anybody can try it and get the 
> same results. I am perfectly aware that this example is a little bit 
> biased (like most performance figures), but that's to make my point.
>
>> AspectJ will optimize any use of thisJoinPoint that uses only the 
>> "thisJoinPointStaticPart" of the JoinPoint interface. 
>> "thisJoinPoint.getArgs()" falls out of that contract, because it 
>> returns the actual argument array. The statically knowable subset of 
>> join point information can be no different between Spoon-AOP and 
>> AspectJ (or any other Java-based AOP implementation).
>
>
> Really? Well, I took this example exactly because in AspectJ, you 
> cannot access the number of parameters as static information. In 
> Spoon-AOP you can. So I can write an advice that says:
>
> if(_argumentCount_==0) { do_0 }
> if(_argumentCount_==1) { do_1 }
> if(_argumentCount_>=2) { do_gte_2 }
>
> And there will be no overhead.
>
> Even better, if the number of arguments is 1 for a given joinpoint, 
> the woven code will be exactly (partial evaluation):
>
> do_1
>
> If you want to know all the information that Spoon-AOP can statically 
> access, you can refer to the template parameters defined in the Aspect 
> class: http://www.lifl.fr/~pawlak/spoon-aop/javadoc/spoon/aop/Aspect.html
>
> Anyway, in addition to these statically known info about the 
> joinpoint, Spoon-AOP is open by using compile-time reflection, 
> similarly to Josh: 
> http://www.csg.is.titech.ac.jp/paper/chiba-aosd2004.pdf
>
> It means that any aspect can define new static info by introspecting a 
> Java metamodel provided by Spoon at compile time. For example, let's 
> say I want to add an information that tells me if a method uses a 
> field f, well I can do it with Spoon-AOP (and use it in my advice with 
> no runtime overhead)!
>
>>
>> In AspectJ you can:
>>
>> * implement the example much more efficiently using a pointcut:  
>> before() : execution(* ToBeAdvised.*(*,..)) { ... }
>
>
> I have never seen that before. Does it mean that you capture all the 
> methods that have more than zero arguments? Well, in that case, I have 
> to say two things:
>
> - if you want to implement my example, you have to write two pieces of 
> advice (one for the case argCount is 0 and one otherwise). I don't 
> think that it is very nice or readable.
> - what if you want to do something special in case there are 3 
> arguments (for instance)?
>
>> * in general, bind the contextual information you need explicitly, 
>> giving you typed advice and no overhead
>
>
> Yep, but it will also give you less reusable advice code and pointcuts 
> (LESS reusable aspects in general). Sometimes, you want to perform 
> GENERIC actions, with minimal information, but with no overhead. It is 
> most of the time not possible with AspectJ.
>
>> * use thisJoinPointStaticPart (or the static parts of thisJoinPoint, 
>> which will be optimised to give the same result)
>
>
> I'd like too, but sometimes I'd like not.
>
>> * only use the full thisJoinPoint object when you really need runtime 
>> access to the actual this, target, and args objects (and then there 
>> are lazyTjp optimizations that will also kick in)
>
>
> I don't know about this. Is it some kind of partial evaluation? Spoon 
> already support partial evaluation during the weaving process. That's 
> why it is so fast in my example, without requiring any special JVM 
> enhancements.
>
>>
>> The JoinPoint implementation is also not based on java.lang.reflect 
>> under the covers (you state otherwise).
>
>
> Ooops! I will change it, but I would be very interested in knowing 
> exactly how it is done then, because I lack time to dive into AspectJ 
> sources... Note that java.lang.reflect is very optimized nowadays and 
> that's why I assumed that it was use here. I'm surprised.
>
>>
>> In what way do you believe Spoon-AOP is "better typed" than most of 
>> the classical AOP approaches? Can you give an example where Spoon-AOP 
>> has stronger typing than an equivalent AspectJ program?
>
>
> Well, I never said that Spoon-AOP was better-typed that AspectJ. 
> Actually, as far as I can tell it is just as well typed.
>
> But, what is interesting here, is that Spoon-AOP is not a new 
> language, but a pure Java framework that uses CT-reflection to extends 
> the Java's semantics. So, compared to the framework approaches (JAC, 
> JBoss-AOP, Spring...), Spoon-AOP is much better typed.
>
> Also, I think that Spoon-AOP is easier to use than AspectJ for a 
> similar type safetyness and better performances.
>
> For instance, with AspectJ, you have to bind the parameters you use 
> when you want type safety and performance. With Spoon-AOP, you can do 
> it in several ways. For instance to advise this method:
>
> @A
> void m(int i, String s) { ... }
>
> You can write this advice:
>
> @A @Before
> void a(int i,String s) {
>   System.out.println("args="+i+","+s);
> }
>
> This is kind of similar to AspectJ where you have to bind the 
> parameters explicitly... BUT it is not reusable. Indeed, it is 
> efficient but it does not work for any number of parameters. A more 
> reusable way of doing it in Spoon-AOP, would be:
>
> @A @Before
> void a() {
>   System.out.print("args=");
>   if(_argumentCount_>=1)
>     System.out.print(","+_arguments_[0]);
>   if(_argumentCount_>=2)
>     System.out.print(","+_arguments_[1]);
>   if(_argumentCount_>=3)
>     System.out.print(","+_arguments_[2]);
>   System.out.println();
> }
>
> These look like untyped argument accesses, but actually they are not. 
> Indeed _arguments_ does not represent the runtime arguments, but **the 
> compile-time argument accesses**. Then, the compilation phase for the 
> woven code will perform the type checking. For instance, with the 
> method m(int i, String s), the woven code will be (after partial 
> evaluation):
>
> void m(int i, String s) {
>   System.out.print("args=");
>   System.out.print(","+i);
>   System.out.print(","+s);
>   System.out.println();
>   ... // original m code
> }
>
> ..., which is more efficient than a reflective version...
>
> (Note that I could also make a foreach loop (finite loop), but my 
> partial evaluator does not know how to deal with these yet.)
>
> Whatever, I feel like I said too much already and that nobody will 
> read this. Once again, this is ongoing work and I am sure that there 
> are still a lot of defects. Also, it will be hard to defend it by 
> myself if nobody comes and see what it does exactly... So I'd like to 
> encourage anybody that would have some extra time to try it and to 
> report on it :)
>
> Cheers,
> /Renaud
>
>>
>> Renaud Pawlak wrote:
>>
>>> Dear all,
>>>
>>> It is my pleasure to announce here the first release of Spoon: a 
>>> powerful Java 5 annotation processing tool.
>>>
>>> It is available in Open Source at http://spoon.gforge.inria.fr/
>>>
>>> Spoon is similar to APT 
>>> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html) 
>>> except that it provides a full metamodel of Java 5 (also models the 
>>> Java code in the method bodies) and that it implements compile-time 
>>> reflection. So, Spoon can be used for more in-depth and fine-grained 
>>> program transformation and analysis.
>>>
>>> In addition, for specifying the transformations, Spoon allows the 
>>> use of pure-Java templates (which can be compared to Velocity 
>>> templates except that they are written in Java and, as such, 
>>> directly benefit the IDE support for type soundness, navigation, and 
>>> other features).
>>>
>>> Finally, let me point out for you a small application of Spoon: an 
>>> original and efficient annotation-driven AOP weaver called 
>>> "Spoon-AOP" available at http://www.lifl.fr/~pawlak/spoon-aop/
>>>
>>> Enjoy!
>>> /Renaud
>>>
>>
>>
>>
>> __________________________________________________
>> AOSD Discuss mailing list    -    di...@ao...
>> To unsubscribe go to http://aosd.net
>>
>> Check out the AOSD.net Wiki: http://aosd.net/wiki
>>
>
>

Hi,

On Jan 31, 2006, at 13:23 , Renaud Pawlak wrote:
>> The JoinPoint implementation is also not based on =20
>> java.lang.reflect under the covers (you state otherwise).
>
> Ooops! I will change it, but I would be very interested in knowing =20
> exactly how it is done then, because I lack time to dive into =20
> AspectJ sources... Note that java.lang.reflect is very optimized =20
> nowadays and that's why I assumed that it was use here. I'm surprised.

Just to add a bit on that.

In previous versions of Reflex we used the reflection API for =20
proceed, assuming it was sufficiently optimized. Then we did some =20
benchmarks on AspectJ-over-Reflex vs. AspectJ alone, and had =20
reasonable 10-15% overhead for most cases, as was to be expected, =20
except precisely for the cases with proceed [1]. We therefore assumed =20=

the use of java.lang.reflect was the source of overhead. We have now =20
implemented the same optimization as in AspectJ (ie, generate stub =20
methods that do proceed "directly") and got very good results.

So btw, apart from the fact that the reflective API is not as =20
efficient as one would (like to) believe, there are other AOP systems =20=

that do not rely on it. AspectJ is one, Reflex is another, and there =20
might be others as well.


-- Eric

[1] L. Rodr=EDguez, =C9. Tanter, J. Noy=E9 - "Supporting Dynamic =20
Crosscutting with Partial Behavioral Reflection: A Case Study", =20
Proceedings of SCCC 2004 (extended/corrected version in French to =20
appear in l'Objet).

> Hi Renaud
> That 's great work!

Thanks Alex.

I forward to the di...@ao... mailing list so that they can have=20
access to the source I provide in this email.

>=20
> Have you looked at Java 6' APT - that is supposed to expose all the
> metamodel as well ?
> As far as I know the limitations there is that it won't allow for
> in-code replacement that is only code/artifact creation.
> But I think Sun' Jackpot project is more similar to what Spoon does.
> May be you discussed with those guys.

No. But I'd like to. I have actually proposed myself to be part of the=20
JSR 269 in the name of INRIA, but I don't really know how it works and I=20
am not sure they need help there.

>=20
> The AOP implementation you propose with Spoon is limited in the sense
> it requires source  as input (hence no weaving in 3rd parties
> libraries)

Well, Spoon can take classes (jars, zips, dirs) and disassemble the=20
bytecode to process them. I do not think that it is a fundamental=20
limitation, but more a technical choice. I will also support=20
calling-side advising, which will reduce this limitation.

  - and I also be interested in looking / reproducing the
> performance figures you quote on Spoon compared to AspectJ - is that
> in the CVS ?

Nope. But it is really easy to do it.

Here is the main:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
package testAJ;

public class Main {

     static int nb =3D 20000000;
     static int nb_passes =3D 10;

     // static int nb=3D1;

     public static void main(String[] args) {
         ToBeAdvised a =3D new ToBeAdvised();
         System.out.println("starting bench... ");
         long[] passes =3D new long[nb_passes];
         for (int pass =3D 0; pass < nb_passes; pass++) {
             long t1 =3D System.currentTimeMillis();
             for (int i =3D 0; i < nb; i++) {
                 a.aMethod1("test");
                 a.aMethod2(0);
             }
             long t2 =3D System.currentTimeMillis();
             passes[pass] =3D t2 - t1;
         }
         float f=3D0;
         for(long l:passes) {
             f+=3Dl;
         }
         System.out.println("finished in " + (f/nb_passes) + " ms");
     }

}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Here is the advised class

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
public class ToBeAdvised {

     public int aMethod1(String s) {
         return 0;
     }

     public int aMethod2(int i) {
         return i + 1;
     }

}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The aspects are like provided on my web page.

Cheers
/Renaud

>=20
> Alex
>=20
>=20
>=20
> On 1/30/06, Renaud Pawlak <ren...@in...> wrote:
>> Dear all,
>>
>> It is my pleasure to announce here the first release of Spoon: a
>> powerful Java 5 annotation processing tool.
>>
>> It is available in Open Source at http://spoon.gforge.inria.fr/
>>
>> Spoon is similar to APT
>> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html)
>> except that it provides a full metamodel of Java 5 (also models the Ja=
va
>> code in the method bodies) and that it implements compile-time
>> reflection. So, Spoon can be used for more in-depth and fine-grained
>> program transformation and analysis.
>>
>> In addition, for specifying the transformations, Spoon allows the use =
of
>> pure-Java templates (which can be compared to Velocity templates excep=
t
>> that they are written in Java and, as such, directly benefit the IDE
>> support for type soundness, navigation, and other features).
>>
>> Finally, let me point out for you a small application of Spoon: an
>> original and efficient annotation-driven AOP weaver called "Spoon-AOP"
>> available at http://www.lifl.fr/~pawlak/spoon-aop/
>>
>> Enjoy!
>> /Renaud
>>
>> --
>> Renaud Pawlak
>> Researcher
>> INRIA Futurs - Projet JACQUARD
>> LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
>> 59655 Villeneuve d'Ascq C=E9dex - FRANCE
>> Phone:  (+33) 3 28 77 85 79
>> Cell:   (+33) 6 62 00 19 19
>> Fax:    (+33) 3 28 77 85 37
>> Emails: ren...@in... / pa...@li...
>> WWW:    http://www.lifl.fr/~pawlak
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log=
 files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK=
!
>> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
>> _______________________________________________
>> aopalliance-discuss mailing list
>> aop...@li...
>> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>>
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd____________________________________=
___________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>=20


--=20
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone:  (+33) 3 28 77 85 79
Cell:   (+33) 6 62 00 19 19
Fax:    (+33) 3 28 77 85 37
Emails: ren...@in... / pa...@li...
WWW:    http://www.lifl.fr/~pawlak

Hi Adrian,

As I said on the Spoon-AOP page, this is on-going work and I need to=20
investigate and explain more what it does exactly. For the moment, it=20
may seem a little bit "magic" when you do not know about Spoon templates=20
and I am sorry about this. I will complete and explain better when my=20
time will allow me.

However, I would like to explain myself a little bit better in this=20
email and answer some of your questions.

> into spoon itself yet). Your comment on the AspectJ performance is a=20
> little misleading.=20

I am sorry about this, but it is hard to cover all the details of things=20
when you want to make a clear point. Here, the code I show gives the=20
results I put in my table. Anybody can try it and get the same results.=20
I am perfectly aware that this example is a little bit biased (like most=20
performance figures), but that's to make my point.

> AspectJ will optimize any use of thisJoinPoint that=20
> uses only the "thisJoinPointStaticPart" of the JoinPoint interface.=20
> "thisJoinPoint.getArgs()" falls out of that contract, because it return=
s=20
> the actual argument array. The statically knowable subset of join point=
=20
> information can be no different between Spoon-AOP and AspectJ (or any=20
> other Java-based AOP implementation).

Really? Well, I took this example exactly because in AspectJ, you cannot=20
access the number of parameters as static information. In Spoon-AOP you=20
can. So I can write an advice that says:

if(_argumentCount_=3D=3D0) { do_0 }
if(_argumentCount_=3D=3D1) { do_1 }
if(_argumentCount_>=3D2) { do_gte_2 }

And there will be no overhead.

Even better, if the number of arguments is 1 for a given joinpoint, the=20
woven code will be exactly (partial evaluation):

do_1

If you want to know all the information that Spoon-AOP can statically=20
access, you can refer to the template parameters defined in the Aspect=20
class: http://www.lifl.fr/~pawlak/spoon-aop/javadoc/spoon/aop/Aspect.html

Anyway, in addition to these statically known info about the joinpoint,=20
Spoon-AOP is open by using compile-time reflection, similarly to Josh:=20
http://www.csg.is.titech.ac.jp/paper/chiba-aosd2004.pdf

It means that any aspect can define new static info by introspecting a=20
Java metamodel provided by Spoon at compile time. For example, let's say=20
I want to add an information that tells me if a method uses a field f,=20
well I can do it with Spoon-AOP (and use it in my advice with no runtime=20
overhead)!

>=20
> In AspectJ you can:
>=20
> * implement the example much more efficiently using a pointcut: =20
> before() : execution(* ToBeAdvised.*(*,..)) { ... }

I have never seen that before. Does it mean that you capture all the=20
methods that have more than zero arguments? Well, in that case, I have=20
to say two things:

- if you want to implement my example, you have to write two pieces of=20
advice (one for the case argCount is 0 and one otherwise). I don't think=20
that it is very nice or readable.
- what if you want to do something special in case there are 3 arguments=20
(for instance)?

> * in general, bind the contextual information you need explicitly,=20
> giving you typed advice and no overhead

Yep, but it will also give you less reusable advice code and pointcuts=20
(LESS reusable aspects in general). Sometimes, you want to perform=20
GENERIC actions, with minimal information, but with no overhead. It is=20
most of the time not possible with AspectJ.

> * use thisJoinPointStaticPart (or the static parts of thisJoinPoint,=20
> which will be optimised to give the same result)

I'd like too, but sometimes I'd like not.

> * only use the full thisJoinPoint object when you really need runtime=20
> access to the actual this, target, and args objects (and then there are=
=20
> lazyTjp optimizations that will also kick in)

I don't know about this. Is it some kind of partial evaluation? Spoon=20
already support partial evaluation during the weaving process. That's=20
why it is so fast in my example, without requiring any special JVM=20
enhancements.

>=20
> The JoinPoint implementation is also not based on java.lang.reflect=20
> under the covers (you state otherwise).

Ooops! I will change it, but I would be very interested in knowing=20
exactly how it is done then, because I lack time to dive into AspectJ=20
sources... Note that java.lang.reflect is very optimized nowadays and=20
that's why I assumed that it was use here. I'm surprised.

>=20
> In what way do you believe Spoon-AOP is "better typed" than most of the=
=20
> classical AOP approaches? Can you give an example where Spoon-AOP has=20
> stronger typing than an equivalent AspectJ program?

Well, I never said that Spoon-AOP was better-typed that AspectJ.=20
Actually, as far as I can tell it is just as well typed.

But, what is interesting here, is that Spoon-AOP is not a new language,=20
but a pure Java framework that uses CT-reflection to extends the Java's=20
semantics. So, compared to the framework approaches (JAC, JBoss-AOP,=20
Spring...), Spoon-AOP is much better typed.

Also, I think that Spoon-AOP is easier to use than AspectJ for a similar=20
type safetyness and better performances.

For instance, with AspectJ, you have to bind the parameters you use when=20
you want type safety and performance. With Spoon-AOP, you can do it in=20
several ways. For instance to advise this method:

@A
void m(int i, String s) { ... }

You can write this advice:

@A @Before
void a(int i,String s) {
   System.out.println("args=3D"+i+","+s);
}

This is kind of similar to AspectJ where you have to bind the parameters=20
explicitly... BUT it is not reusable. Indeed, it is efficient but it=20
does not work for any number of parameters. A more reusable way of doing=20
it in Spoon-AOP, would be:

@A @Before
void a() {
   System.out.print("args=3D");
   if(_argumentCount_>=3D1)
     System.out.print(","+_arguments_[0]);
   if(_argumentCount_>=3D2)
     System.out.print(","+_arguments_[1]);
   if(_argumentCount_>=3D3)
     System.out.print(","+_arguments_[2]);
   System.out.println();
}

These look like untyped argument accesses, but actually they are not.=20
Indeed _arguments_ does not represent the runtime arguments, but **the=20
compile-time argument accesses**. Then, the compilation phase for the=20
woven code will perform the type checking. For instance, with the method=20
m(int i, String s), the woven code will be (after partial evaluation):

void m(int i, String s) {
   System.out.print("args=3D");
   System.out.print(","+i);
   System.out.print(","+s);
   System.out.println();
   ... // original m code
}

..., which is more efficient than a reflective version...

(Note that I could also make a foreach loop (finite loop), but my=20
partial evaluator does not know how to deal with these yet.)

Whatever, I feel like I said too much already and that nobody will read=20
this. Once again, this is ongoing work and I am sure that there are=20
still a lot of defects. Also, it will be hard to defend it by myself if=20
nobody comes and see what it does exactly... So I'd like to encourage=20
anybody that would have some extra time to try it and to report on it :)

Cheers,
/Renaud

>=20
> Renaud Pawlak wrote:
>=20
>> Dear all,
>>
>> It is my pleasure to announce here the first release of Spoon: a=20
>> powerful Java 5 annotation processing tool.
>>
>> It is available in Open Source at http://spoon.gforge.inria.fr/
>>
>> Spoon is similar to APT=20
>> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html)=20
>> except that it provides a full metamodel of Java 5 (also models the=20
>> Java code in the method bodies) and that it implements compile-time=20
>> reflection. So, Spoon can be used for more in-depth and fine-grained=20
>> program transformation and analysis.
>>
>> In addition, for specifying the transformations, Spoon allows the use=20
>> of pure-Java templates (which can be compared to Velocity templates=20
>> except that they are written in Java and, as such, directly benefit=20
>> the IDE support for type soundness, navigation, and other features).
>>
>> Finally, let me point out for you a small application of Spoon: an=20
>> original and efficient annotation-driven AOP weaver called "Spoon-AOP"=
=20
>> available at http://www.lifl.fr/~pawlak/spoon-aop/
>>
>> Enjoy!
>> /Renaud
>>
>=20
>=20
>=20
> __________________________________________________
> AOSD Discuss mailing list    -    di...@ao...
> To unsubscribe go to http://aosd.net
>=20
> Check out the AOSD.net Wiki: http://aosd.net/wiki
>=20


--=20
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone:  (+33) 3 28 77 85 79
Cell:   (+33) 6 62 00 19 19
Fax:    (+33) 3 28 77 85 37
Emails: ren...@in... / pa...@li...
WWW:    http://www.lifl.fr/~pawlak

Hi Renaud,
I took a quick look at the Spoon-AOP page (haven't had a chance to dig 
into spoon itself yet). Your comment on the AspectJ performance is a 
little misleading. AspectJ will optimize any use of thisJoinPoint that 
uses only the "thisJoinPointStaticPart" of the JoinPoint interface. 
"thisJoinPoint.getArgs()" falls out of that contract, because it returns 
the actual argument array. The statically knowable subset of join point 
information can be no different between Spoon-AOP and AspectJ (or any 
other Java-based AOP implementation).

In AspectJ you can:

* implement the example much more efficiently using a pointcut:  
before() : execution(* ToBeAdvised.*(*,..)) { ... }
* in general, bind the contextual information you need explicitly, 
giving you typed advice and no overhead
* use thisJoinPointStaticPart (or the static parts of thisJoinPoint, 
which will be optimised to give the same result)
* only use the full thisJoinPoint object when you really need runtime 
access to the actual this, target, and args objects (and then there are 
lazyTjp optimizations that will also kick in)

The JoinPoint implementation is also not based on java.lang.reflect 
under the covers (you state otherwise).

In what way do you believe Spoon-AOP is "better typed" than most of the 
classical AOP approaches? Can you give an example where Spoon-AOP has 
stronger typing than an equivalent AspectJ program?

Renaud Pawlak wrote:

>
> Dear all,
>
> It is my pleasure to announce here the first release of Spoon: a 
> powerful Java 5 annotation processing tool.
>
> It is available in Open Source at http://spoon.gforge.inria.fr/
>
> Spoon is similar to APT 
> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html) 
> except that it provides a full metamodel of Java 5 (also models the 
> Java code in the method bodies) and that it implements compile-time 
> reflection. So, Spoon can be used for more in-depth and fine-grained 
> program transformation and analysis.
>
> In addition, for specifying the transformations, Spoon allows the use 
> of pure-Java templates (which can be compared to Velocity templates 
> except that they are written in Java and, as such, directly benefit 
> the IDE support for type soundness, navigation, and other features).
>
> Finally, let me point out for you a small application of Spoon: an 
> original and efficient annotation-driven AOP weaver called "Spoon-AOP" 
> available at http://www.lifl.fr/~pawlak/spoon-aop/
>
> Enjoy!
> /Renaud
>

Hi Renaud
That 's great work!

Have you looked at Java 6' APT - that is supposed to expose all the
metamodel as well ?
As far as I know the limitations there is that it won't allow for
in-code replacement that is only code/artifact creation.
But I think Sun' Jackpot project is more similar to what Spoon does.
May be you discussed with those guys.

The AOP implementation you propose with Spoon is limited in the sense
it requires source  as input (hence no weaving in 3rd parties
libraries) - and I also be interested in looking / reproducing the
performance figures you quote on Spoon compared to AspectJ - is that
in the CVS ?

Alex



On 1/30/06, Renaud Pawlak <ren...@in...> wrote:
>
> Dear all,
>
> It is my pleasure to announce here the first release of Spoon: a
> powerful Java 5 annotation processing tool.
>
> It is available in Open Source at http://spoon.gforge.inria.fr/
>
> Spoon is similar to APT
> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html)
> except that it provides a full metamodel of Java 5 (also models the Java
> code in the method bodies) and that it implements compile-time
> reflection. So, Spoon can be used for more in-depth and fine-grained
> program transformation and analysis.
>
> In addition, for specifying the transformations, Spoon allows the use of
> pure-Java templates (which can be compared to Velocity templates except
> that they are written in Java and, as such, directly benefit the IDE
> support for type soundness, navigation, and other features).
>
> Finally, let me point out for you a small application of Spoon: an
> original and efficient annotation-driven AOP weaver called "Spoon-AOP"
> available at http://www.lifl.fr/~pawlak/spoon-aop/
>
> Enjoy!
> /Renaud
>
> --
> Renaud Pawlak
> Researcher
> INRIA Futurs - Projet JACQUARD
> LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
> 59655 Villeneuve d'Ascq C=E9dex - FRANCE
> Phone:  (+33) 3 28 77 85 79
> Cell:   (+33) 6 62 00 19 19
> Fax:    (+33) 3 28 77 85 37
> Emails: ren...@in... / pa...@li...
> WWW:    http://www.lifl.fr/~pawlak
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>

Dear all,

It is my pleasure to announce here the first release of Spoon: a=20
powerful Java 5 annotation processing tool.

It is available in Open Source at http://spoon.gforge.inria.fr/

Spoon is similar to APT=20
(http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html)=20
except that it provides a full metamodel of Java 5 (also models the Java=20
code in the method bodies) and that it implements compile-time=20
reflection. So, Spoon can be used for more in-depth and fine-grained=20
program transformation and analysis.

In addition, for specifying the transformations, Spoon allows the use of=20
pure-Java templates (which can be compared to Velocity templates except=20
that they are written in Java and, as such, directly benefit the IDE=20
support for type soundness, navigation, and other features).

Finally, let me point out for you a small application of Spoon: an=20
original and efficient annotation-driven AOP weaver called "Spoon-AOP"=20
available at http://www.lifl.fr/~pawlak/spoon-aop/

Enjoy!
/Renaud

--=20
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone:  (+33) 3 28 77 85 79
Cell:   (+33) 6 62 00 19 19
Fax:    (+33) 3 28 77 85 37
Emails: ren...@in... / pa...@li...
WWW:    http://www.lifl.fr/~pawlak

Hi, have you think in extending the AOPAlliance for NET plataform or the
idea is to keep it only for Java?

regards,
Nicolaz

------------------------------
Nicol=E1s Paez
Departamente de Computaci=F3n
Facultad de Ingenier=EDa - UBA

Alex, thank for pointing this out, it is a useful question!

This new book is mainly a translation, as we wanted the non-French=20
readers to access this information.

However, we have updated many of the contents with new features of the=20
AOP tools when needed. In particular, AspectJ 5 is presented and=20
AspectWerkz has been merged to it. JBoss-AOP has been updated with the=20
latest release features. Besides, an entire new chapter has been added=20
on Spring-AOP.

Finally, the style and the presentation have been enhanced to be more=20
direct and simplier to understand (with sometimes less details for=20
clarity sake).

To be as clear and honest as possible, for those how already have the=20
French version (and can read French), I do not think that it is worth=20
buying the English version, except if you really enjoyed the book and=20
badly want an update on new AOP tools features :)

Cheers,
/Renaud

Alexandre Vasseur wrote:

> thanks Renaud
> One more (for French folks): how does this new book compares to your
> one on Eyrolle (may 2004, same title, same authors) ?
> http://www.editions-eyrolles.com/Livre/9782212114089/programmation-orie=
ntee-aspect-pour-java-j2ee?xd=3D1c35f4375d5e00865caaaa90547250fa
>=20
>=20
> Alex
>=20
> On 9/28/05, Renaud Pawlak <ren...@in...> wrote:
>=20
>>The *core* of JAC can indeed be used in an J2EE environment, as it does
>>not make any special assumption of the form of the objects it is workin=
g
>>on. The problem that would probably necessitate some adaptations though
>>would be the classloader (which might be incompatible with other
>>classloaders). But this is a secondary technical detail.
>>
>>Basically, you have to see the core of JAC as an interception framework
>>that is independent from any technology and that can be used in many
>>contexts.
>>
>>However, there has been a lot of work done around JAC (like the
>>persistence or the GUI aspects for instance). Unfortunatly, all this
>>rely on developments which are specific to JAC and that are not very
>>compatible to typical J2EE APIs. This implies that you cannot really us=
e
>>them for "regular" J2EE developments.
>>
>>JAC has several levels and is very open. You can use JAC by using the
>>UMLAF IDE with all the provided aspects, or you can use only the core
>>API and rewrite your own aspects to work with standard J2EE API.
>>
>>I think that we have had a communication problem with JAC. We have trie=
d
>>to hide the complexity of AOP by providing "off-the-shelf" aspects. JAC
>>was too much in advance and ambitious to that matter. So, people usuall=
y
>>think of JAC as a full-blown environment but actually it is not. Of
>>course, before providing all our aspects, we have had to go through all
>>the core interception and pointcut framework (as many projects have don=
e
>>later in the J2EE context --- some by getting a lot of ideas from JAC).
>>
>>It was definitily a stategic mistake not to tight ourself up to J2EE
>>from the begining. However, JAC has the merit to show that it is
>>possible to build a full J2EE-like environment only with aspects and it
>>remain a good case study and a core framework for AOP (which is usable
>>in J2EE if you just use the core by itself -- however, I think that
>>nobody never did this because JAC was not advertized and packaged for
>>that use).
>>
>>I hope this makes think clearer...
>>
>>Cheers,
>>/Renaud
>>
>>
>>
>>Alexandre Vasseur wrote:
>>
>>
>>>can JAC be used in a J2EE app server ? I though JAC was itself sort of
>>>a full blown environment.
>>>Alex
>>>
>>>On 9/27/05, Lionel Seinturier <lio...@li...> wrote:
>>>
>>>
>>>>It is our pleasure to announce that our book on AOP for J2EE developm=
ent
>>>>is now available.
>>>>
>>>>Foundations of AOP for J2EE Development
>>>>R. Pawlak, J.-P. Retaill=E9, L. Seinturier
>>>>Publisher: APress, ISBN 1-59059-507-6, September 2005.
>>>>
>>>>http://www.apress.com/book/bookDisplay.html?bID=3D435
>>>>
>>>>"Foundations of AOP for J2EE Development" covers the programming of
>>>>aspect-oriented applications. The book presents the core concepts of =
AOP
>>>>and their implementations in four existing products: AspectJ 5, JBoss
>>>>AOP, Spring AOP, and JAC. Specific features of these tools are compar=
ed.
>>>>The book also explores the potential uses of AOP in everyday programm=
ing
>>>>life, such as design patterns implementation, program testing, and
>>>>application management.
>>>>
>>>>This book aims at presenting the concepts of AOP in a clear and
>>>>pedagogical way. No prior knowledge of the domain is needed. Instead =
of
>>>>focusing on the advanced programming concepts of a particular AOP
>>>>language, this book provides a broad overview of the existing product=
s
>>>>available for programming with aspects.
>>>>
>>>>In the latter part of the book, we show how AOP can ease the task of
>>>>J2EE application development. This case study shows how AOP can impro=
ve
>>>>the implementation of the business tier and of the presentation tier =
for
>>>>any J2EE application.
>>>>
>>>>R. Pawlak
>>>>J.-P. Retaill=E9
>>>>L. Seinturier
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by:
>>>>Power Architecture Resource Center: Free content, downloads, discussi=
ons,
>>>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>>_______________________________________________
>>>>aopalliance-discuss mailing list
>>>>aop...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by:
>>>Power Architecture Resource Center: Free content, downloads, discussio=
ns,
>>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>_______________________________________________
>>>aopalliance-discuss mailing list
>>>aop...@li...
>>>https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>>>
>>
>>
>>--
>>Renaud Pawlak
>>Researcher
>>INRIA Futurs - Projet JACQUARD
>>LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
>>59655 Villeneuve d'Ascq C=E9dex - FRANCE
>>Phone:  (+33) 3 28 77 85 79
>>Cell:   (+33) 6 62 00 19 19
>>Fax:    (+33) 3 28 77 85 37
>>Emails: ren...@in... / pa...@li...
>>WWW:    http://www.lifl.fr/~pawlak
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussion=
s,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>aopalliance-discuss mailing list
>>aop...@li...
>>https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>>
>>
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussion=
s,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>=20


--=20
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone:  (+33) 3 28 77 85 79
Cell:   (+33) 6 62 00 19 19
Fax:    (+33) 3 28 77 85 37
Emails: ren...@in... / pa...@li...
WWW:    http://www.lifl.fr/~pawlak

thanks Renaud
One more (for French folks): how does this new book compares to your
one on Eyrolle (may 2004, same title, same authors) ?
http://www.editions-eyrolles.com/Livre/9782212114089/programmation-orientee=
-aspect-pour-java-j2ee?xd=3D1c35f4375d5e00865caaaa90547250fa


Alex

On 9/28/05, Renaud Pawlak <ren...@in...> wrote:
>
> The *core* of JAC can indeed be used in an J2EE environment, as it does
> not make any special assumption of the form of the objects it is working
> on. The problem that would probably necessitate some adaptations though
> would be the classloader (which might be incompatible with other
> classloaders). But this is a secondary technical detail.
>
> Basically, you have to see the core of JAC as an interception framework
> that is independent from any technology and that can be used in many
> contexts.
>
> However, there has been a lot of work done around JAC (like the
> persistence or the GUI aspects for instance). Unfortunatly, all this
> rely on developments which are specific to JAC and that are not very
> compatible to typical J2EE APIs. This implies that you cannot really use
> them for "regular" J2EE developments.
>
> JAC has several levels and is very open. You can use JAC by using the
> UMLAF IDE with all the provided aspects, or you can use only the core
> API and rewrite your own aspects to work with standard J2EE API.
>
> I think that we have had a communication problem with JAC. We have tried
> to hide the complexity of AOP by providing "off-the-shelf" aspects. JAC
> was too much in advance and ambitious to that matter. So, people usually
> think of JAC as a full-blown environment but actually it is not. Of
> course, before providing all our aspects, we have had to go through all
> the core interception and pointcut framework (as many projects have done
> later in the J2EE context --- some by getting a lot of ideas from JAC).
>
> It was definitily a stategic mistake not to tight ourself up to J2EE
> from the begining. However, JAC has the merit to show that it is
> possible to build a full J2EE-like environment only with aspects and it
> remain a good case study and a core framework for AOP (which is usable
> in J2EE if you just use the core by itself -- however, I think that
> nobody never did this because JAC was not advertized and packaged for
> that use).
>
> I hope this makes think clearer...
>
> Cheers,
> /Renaud
>
>
>
> Alexandre Vasseur wrote:
>
> > can JAC be used in a J2EE app server ? I though JAC was itself sort of
> > a full blown environment.
> > Alex
> >
> > On 9/27/05, Lionel Seinturier <lio...@li...> wrote:
> >
> >>It is our pleasure to announce that our book on AOP for J2EE developmen=
t
> >>is now available.
> >>
> >>Foundations of AOP for J2EE Development
> >>R. Pawlak, J.-P. Retaill=E9, L. Seinturier
> >>Publisher: APress, ISBN 1-59059-507-6, September 2005.
> >>
> >>http://www.apress.com/book/bookDisplay.html?bID=3D435
> >>
> >>"Foundations of AOP for J2EE Development" covers the programming of
> >>aspect-oriented applications. The book presents the core concepts of AO=
P
> >>and their implementations in four existing products: AspectJ 5, JBoss
> >>AOP, Spring AOP, and JAC. Specific features of these tools are compared=
.
> >>The book also explores the potential uses of AOP in everyday programmin=
g
> >>life, such as design patterns implementation, program testing, and
> >>application management.
> >>
> >>This book aims at presenting the concepts of AOP in a clear and
> >>pedagogical way. No prior knowledge of the domain is needed. Instead of
> >>focusing on the advanced programming concepts of a particular AOP
> >>language, this book provides a broad overview of the existing products
> >>available for programming with aspects.
> >>
> >>In the latter part of the book, we show how AOP can ease the task of
> >>J2EE application development. This case study shows how AOP can improve
> >>the implementation of the business tier and of the presentation tier fo=
r
> >>any J2EE application.
> >>
> >>R. Pawlak
> >>J.-P. Retaill=E9
> >>L. Seinturier
> >>
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by:
> >>Power Architecture Resource Center: Free content, downloads, discussion=
s,
> >>and more. http://solutions.newsforge.com/ibmarch.tmpl
> >>_______________________________________________
> >>aopalliance-discuss mailing list
> >>aop...@li...
> >>https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads, discussion=
s,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > aopalliance-discuss mailing list
> > aop...@li...
> > https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
> >
>
>
> --
> Renaud Pawlak
> Researcher
> INRIA Futurs - Projet JACQUARD
> LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
> 59655 Villeneuve d'Ascq C=E9dex - FRANCE
> Phone:  (+33) 3 28 77 85 79
> Cell:   (+33) 6 62 00 19 19
> Fax:    (+33) 3 28 77 85 37
> Emails: ren...@in... / pa...@li...
> WWW:    http://www.lifl.fr/~pawlak
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>
>

The *core* of JAC can indeed be used in an J2EE environment, as it does=20
not make any special assumption of the form of the objects it is working=20
on. The problem that would probably necessitate some adaptations though=20
would be the classloader (which might be incompatible with other=20
classloaders). But this is a secondary technical detail.

Basically, you have to see the core of JAC as an interception framework=20
that is independent from any technology and that can be used in many=20
contexts.

However, there has been a lot of work done around JAC (like the=20
persistence or the GUI aspects for instance). Unfortunatly, all this=20
rely on developments which are specific to JAC and that are not very=20
compatible to typical J2EE APIs. This implies that you cannot really use=20
them for "regular" J2EE developments.

JAC has several levels and is very open. You can use JAC by using the=20
UMLAF IDE with all the provided aspects, or you can use only the core=20
API and rewrite your own aspects to work with standard J2EE API.

I think that we have had a communication problem with JAC. We have tried=20
to hide the complexity of AOP by providing "off-the-shelf" aspects. JAC=20
was too much in advance and ambitious to that matter. So, people usually=20
think of JAC as a full-blown environment but actually it is not. Of=20
course, before providing all our aspects, we have had to go through all=20
the core interception and pointcut framework (as many projects have done=20
later in the J2EE context --- some by getting a lot of ideas from JAC).

It was definitily a stategic mistake not to tight ourself up to J2EE=20
from the begining. However, JAC has the merit to show that it is=20
possible to build a full J2EE-like environment only with aspects and it=20
remain a good case study and a core framework for AOP (which is usable=20
in J2EE if you just use the core by itself -- however, I think that=20
nobody never did this because JAC was not advertized and packaged for=20
that use).

I hope this makes think clearer...

Cheers,
/Renaud



Alexandre Vasseur wrote:

> can JAC be used in a J2EE app server ? I though JAC was itself sort of
> a full blown environment.
> Alex
>=20
> On 9/27/05, Lionel Seinturier <lio...@li...> wrote:
>=20
>>It is our pleasure to announce that our book on AOP for J2EE developmen=
t
>>is now available.
>>
>>Foundations of AOP for J2EE Development
>>R. Pawlak, J.-P. Retaill=E9, L. Seinturier
>>Publisher: APress, ISBN 1-59059-507-6, September 2005.
>>
>>http://www.apress.com/book/bookDisplay.html?bID=3D435
>>
>>"Foundations of AOP for J2EE Development" covers the programming of
>>aspect-oriented applications. The book presents the core concepts of AO=
P
>>and their implementations in four existing products: AspectJ 5, JBoss
>>AOP, Spring AOP, and JAC. Specific features of these tools are compared.
>>The book also explores the potential uses of AOP in everyday programmin=
g
>>life, such as design patterns implementation, program testing, and
>>application management.
>>
>>This book aims at presenting the concepts of AOP in a clear and
>>pedagogical way. No prior knowledge of the domain is needed. Instead of
>>focusing on the advanced programming concepts of a particular AOP
>>language, this book provides a broad overview of the existing products
>>available for programming with aspects.
>>
>>In the latter part of the book, we show how AOP can ease the task of
>>J2EE application development. This case study shows how AOP can improve
>>the implementation of the business tier and of the presentation tier fo=
r
>>any J2EE application.
>>
>>R. Pawlak
>>J.-P. Retaill=E9
>>L. Seinturier
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussion=
s,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>aopalliance-discuss mailing list
>>aop...@li...
>>https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>>
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussion=
s,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>=20


--=20
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone:  (+33) 3 28 77 85 79
Cell:   (+33) 6 62 00 19 19
Fax:    (+33) 3 28 77 85 37
Emails: ren...@in... / pa...@li...
WWW:    http://www.lifl.fr/~pawlak

Alex,

On 28/09/2005 10:48, Alexandre Vasseur wrote:

> can JAC be used in a J2EE app server ? I though JAC was itself sort of
> a full blown environment.

We should have mentionned that the case study has been conducted with=20
AspectJ. JAC is presented in the 1st part of the book, which presents=20
and compares the 4 mentioned AOP language/frameworks.

Lionel.

> Alex
>=20
> On 9/27/05, Lionel Seinturier <lio...@li...> wrote:
>=20
>>It is our pleasure to announce that our book on AOP for J2EE developmen=
t
>>is now available.
>>
>>Foundations of AOP for J2EE Development
>>R. Pawlak, J.-P. Retaill=E9, L. Seinturier
>>Publisher: APress, ISBN 1-59059-507-6, September 2005.
>>
>>http://www.apress.com/book/bookDisplay.html?bID=3D435
>>
>>"Foundations of AOP for J2EE Development" covers the programming of
>>aspect-oriented applications. The book presents the core concepts of AO=
P
>>and their implementations in four existing products: AspectJ 5, JBoss
>>AOP, Spring AOP, and JAC. Specific features of these tools are compared.
>>The book also explores the potential uses of AOP in everyday programmin=
g
>>life, such as design patterns implementation, program testing, and
>>application management.
>>
>>This book aims at presenting the concepts of AOP in a clear and
>>pedagogical way. No prior knowledge of the domain is needed. Instead of
>>focusing on the advanced programming concepts of a particular AOP
>>language, this book provides a broad overview of the existing products
>>available for programming with aspects.
>>
>>In the latter part of the book, we show how AOP can ease the task of
>>J2EE application development. This case study shows how AOP can improve
>>the implementation of the business tier and of the presentation tier fo=
r
>>any J2EE application.
>>
>>R. Pawlak
>>J.-P. Retaill=E9
>>L. Seinturier
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussion=
s,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>aopalliance-discuss mailing list
>>aop...@li...
>>https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>>
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussion=
s,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> aopalliance-discuss mailing list
> aop...@li...
> https://lists.sourceforge.net/lists/listinfo/aopalliance-discuss
>=20
>=20

--=20
Lionel Seinturier
Deleg. INRIA Lille - Proj. Jacquard
Univ. Paris 6 - Lab. LIP6 - Theme SRC
http://www-src.lip6.fr/~Lionel.Seinturier