Alexandre Vasseur wrote:
> Renaud, thanks for the clarification
> I fully agree on the concepts and the important role annotations are
> playing now, We AspectWerkz folks and AspectJ folks name that
> annotation driven AOP (while @AspectJ is annotation defined AOP).
> But in that case I assume the annotation to actually mean something to
> the user - like well known @Transaction - middleware specific or
> business specific, and that the specification then defines the
> semantics of this annotation (and possibly interaction with other
> AOP (pointcut driven, or any framework that does the job) would be one
> way to implement those semantics. In that case the user would need a
> tool that represents it in a higher level representation (f.e. @TX
> gutter icon instead of "advised by" information).
I understand that and I totally agree the kind of annotations your are=20
talking about is useful. Any abstraction means is useful. In functional=20
programming, it is useful to be able to define a new function through=20
the composition of existing ones. It is useful to define higher-level=20
annotations, but it is also useful to have elementary ones that help you=20
to construct their semantics. That's what I am saying here.
> AOP would then be one tool (actually the best from my perspective) to
> enable such an annotation driven runtime, among APT or other source
> level transformation tools.
Yes, but what you are saying here is that AOP (or any transformation=20
tool) should be oblivious to the final user, which I disagree with. I do=20
not think that it is possible to have abstract-annotation-driven=20
developement for all the aspects, especially domain-specific ones, and=20
especially at early stages of the development. So, we need a cleanly=20
defined and well-integrated AOP support for the end users, so that when=20
no annotations are available with a specific problem, the end users can=20
easily develop their own aspects (maybe incomplete or not reusable but=20
who cares--except them?)
> On the other hand defining a set of AOPsih annotation to define the
> three concepts you quote seems to be a subset of what the current java
> AOP (combined with possibly Proxies) provides. It makes total sense to
> me to implement that as an add-on model of current AOP like AspectJ
> (as tool support, weaving scenarios, error reporting etc would be
> quite immediate).
Yes again, but it is not incompatible. At least, we would have a common=20
background when talking about the aspectized programs' semantics.
> As per beeing convinced that it provides value to the practionners and
> users is another topic.
> I don't buy the pointcut are hard to materialize upfront in the long
This phrase says it all. "... upfront in the long run". How long is the=20
run? I think that it is pretty long for a whole bunch of aspects, and I=20
am talking about making AOP useful now. We have to leave the system=20
open. Otherwise, AOP will just handle a subset of the possible aspects.
> I think it is as hard to define the right middleware / business
> specific annotation and its semantics as well.=20
That's why we need more elementary annotations as well.
Anyway, I am quite sure that you understand what I am saying. I just=20
think that you are not convinced by the usefulness of it because=20
somewhere, you hope that AOP and the kind of annotations you are talking=20
about will solve all the problems of the end users. I am far from=20
believing this. In some contexts, the separation between business needs=20
and technical problems is not as well defined as it is in the Enterprise=20
development context. For instance, would you apply your approach to=20
develop the guts of an applications server (for instance, a transaction=20
manager, a JDBC driver, or whatever?) Are the aspects are as well=20
defined as they are in the enterprise world?
Note that I am talking of my own experience with JAC here. After several=20
years of development, I found that it would be useful to have more=20
low-level constructs for the aspects, just because in some cases, you=20
don't even want the aspects to be configurable by the end users, and=20
also because you do not care that much about obliviousness (all you want=20
is a better/alternative way of designing your architecture).
> Aside new fetures in
> AOP tools like cross-cutting diff in recent AJDT (something that
> Rickard also implemented in his AOP things) should tackle this issue
> (+ early aspects identification and aspect in modeling phases).
> On 8/27/05, Renaud Pawlak <renaud.pawlak@...> wrote:
>> > So what is the exact goal there ?
>>When we started AOP in Java a few years ago, native annotation support
>>did not exist yet. So we all came up with our own ways for configuring
>>the deployment of the aspects. None of these ways are really standard
>>and they must rely on tools and plugins to be really user friendly. In
>>particular, AOP as we know it ended up being pointcut-driven because it
>>was convenient at the time, and also because pointcuts have the great
>>advantage of materializing crosscuts and to ensure obliviousness.
>>However, pointcut-driven AOP is not always very easy and natural to use.
>>Most of the time, when you build a new program, you go through a lot of
>>tries and refactoring stages as you identify new concerns. As a
>>consequence, the structure of the program is moving a lot and it can be
>>very tedious to identify and define the right pointcuts up-front. Once
>>your program's structure is stabilized, you can then define pointcuts
>>easily but it is most of the time too late because you finally gave up
>>using aspects because they did not give you the flexibility you would
>>need at these early development stages...
>>As a consequence, having the possibility to use AOP just by annotating
>>where you want to advise or introduce would IMO give much more
>>flexibility and would encourage the use of AOP from the begining, and
>>for more domain-specific aspects.
>>So, I guess that I'd say that the first reason for doing this is
>>methodological. However, there is a more profound reason, which I will
>>try to explain here.
>> From an operational point of view, the tree real artifacts that have
>>meaning in AOP are the advising, the introduction, and the cflow. The
>>pointcut is just a way of deploying these. In Java, these artifacts are
>>of course not supported so that they do not have clear meanings and
>>semantics in the Java code. Everybody implements their own semantics fo=
>>these and they are somehow similar, however, for AOP to be clearly
>>defined, it is important to materialize these constructs and to give
>>them a meaning in the Java code. I think that annotations give us the
>>opportunity to do this.
>>By annotating the Java code with standardized annotations for AOP, we
>>would actually specify the aspectized program so that IDEs (and also
>>programmers) exactly know what happens in the program. Plus, it would
>>give a common ground for AO tools to work with, all this in "standard"
>>Java. It is important to understand that it does not prevent anyone fro=
>>continuing doing AOP as we know it (i.e. pointcut-driven AOP). It is
>>just that the pointcuts will be compiled so that they end up annotating
>>the base program with these standard annotations, since it is this
>>representation that actually gives the fully specified program.
>>Note that part of this idea is also present in Gregor's paper at
>>ICSE'05, where he suggests that interfaces should be enhanced to reflec=
>>the applied aspects (the full semantics). I think we should generalize
>>this idea with annotations.
>>>In this case - behind "plain Java / IDE support" buzzwords, it seems
>>>to gear to annotations ala EJB 3 interceptor.
>>>The main difference is that with this addition, you would have to
>>>further define the weaving process, what if several weaving phases are
>>>done, why annotation and not XML (then both ? redoing the AspectWerkz
>>>story then ?), and why not beanshell configuration, etc.
>>Because annotations are native Java constructs. There are integrated in
>>the program and give its full specification. It does not prevent anyone
>>from building configuration tools that would fall back on this final
>>pure Java AO programs.
>>Yes, it is important to define as clearly as possible the semantics of
>>AO constructs (advising, introductions, and cflows) so that we know
>>what's behind the annotations. When you look at an "if" in Java, you
>>know exactly what it does. It has to be the same with AOP constructs.
>>Maybe I am idealistic here, but I do not think that it is impossible to
>>define the semantics of these AOP constructs. Some problems might be
>>encountered (such as the one you mentionned with the synchronized
>>method), but I do not feel like they are impossible to overcome.
>>>This kind of details was not in the initial scope of AOP alliance, and
>>>adding those is likely to drive you in the invention of yet another
>>>AOP framework - though the pointcut is from a different taste
>>Not another AOP framework, but a common base to build AO frameworks wit=
>>a clear execution model.
>> > this kind of spefication would be trivial to implement with
>> > AspectWerkz or AspectJ as some add-on layer)
>>Sure, but it would be totally unatural to do this. To me, you have to
>>define the AO execution model with the right annotations first, and the=
>>build on the top more elaborate features like pointcuts.
>>>As per tools / IDE - AspectJ 5 (the @AspectJ style at least) is IDE
>>>friendly as Adrian described. Ones can also easily add some Java 5 apt
>>>layer to do pointcut validation as well. Even with that, users will
>>>need sort of a crosscutting view (advises/advised by) as provided by
>>>AJDT, so f.e. even with what you suggest, the very same need will
>>>exist (at least for advises).
>>I do not think that you will need this anymore. As Gregor said, the
>>annotations will be well supported in IDEs and it will dramatically
>>simplify the AOP plugins, especially if we do what I suggest.
>>Tools like APT will probably be better integrated in the future and
>>annotation management, program transformation, etc will be more
>>straightforward. I already have a good vision of my crosscuts when I us=
>>the reference management tool (CTRL+ALT+G in Eclipse). I am sure that i=
>>will even get better.
>>I hope that all this verbose email clarifies a little bit the goals of
>>INRIA Futurs - Projet JACQUARD
>>LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
>>59655 Villeneuve d'Ascq C=E9dex - FRANCE
>>Phone: (+33) 328 778579
>>Cell: (+33) 662 001919
>>Fax: (+33) 328 778537
>>Emails: renaud.pawlak@... / pawlak@...
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
>>aopalliance-discuss mailing list
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
> aopalliance-discuss mailing list
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3
59655 Villeneuve d'Ascq C=E9dex - FRANCE
Phone: (+33) 328 778579
Cell: (+33) 662 001919
Fax: (+33) 328 778537
Emails: renaud.pawlak@... / pawlak@...