1 2 Previous Next 29 Replies Latest reply on May 8, 2003 12:32 PM by juhalindfors

    key properties of AOP in Java

    gregork


      This is the first of a couple of message I hope to write on AOP in Java.

      The purpose of the messages is to compare some of the newer proposals,
      like Rickard's, JBoss, Jadvise and AspectWerkz to "good old fashioned"
      AspectJ.

      My goal is not to champion AspectJ over the other proposals. I assume
      there are very good reasons (the "XML issue") for there to be AOP systems for Java other
      than AspectJ.

      Instead my goal is to identify some of the key features of AspectJ that
      I believe other AOP systems should also have, and start a discussion
      about whether the other proposals have those properties, could have
      those properties, and whether it would be a good idea.

      This initial message just enumerates and describes some key properties
      of AspectJ. The message is primarily focused on the pointcuts and
      advice part of AspectJ.


      -elements of the join point model are orthogonal-

      Perhaps the most important property of the AspectJ design is that
      the elements of the join point model are orthogonal. That is, the
      join points, the pointcuts, and the advice are orthogonal -- they
      can be used in any combination. This was one of the hardest things
      to achieve in the design, but it is very important, and it is at
      the core of what leads to several of the other nice properties below.


      -pointcut language is compositional-

      The pointcut language is compositional. This means that you
      can take pointcuts and compose them to form other pointcuts.
      This means that you can build up crosscutting structure in
      a similar manner to what we know about building up procedural
      structure or class structure.


      -pointcut language supports named abstractions-

      The pointcut language supports named abstractions. The user
      can define a pointcut like the well-known move pointcut:

      pointcut move(): call(void FigureElement+.set*(..));

      And then use it elsewhere by name. For example in an advice
      like:

      after() returning: move() {
      Display.update();
      }


      If you aren't familiar with this example, see the tutorial
      at http://www.parc.com/groups/csl/projects/aspectj/


      This is just like the naming we know how to do in procedures
      and methods. The name defines an abstraction, elsewhere we
      can use the abstraction by name.


      The combination of supporting named abstraction and being
      compositional means we can say nice things like:

      after() returning: move() && !cflowbelow(move()) {
      Display.update();
      }

      and easily understand what that means.


      -static typing-

      Pointcut and advice declarations in AspectJ are statically
      typed. This supports separate compilation and it means that
      that actual weaving becomes typesafe. Which means the
      weaving can happen later than compile time, like load time
      or even in the VM.

      For the programmer this means I can be confident, when I see
      an advice like:

      after(FigureElement fe) returning: move(fe) {
      Display.update(fe);
      }

      That this advice will never result in a runtime type error, no
      matter what classes it is woven against.

      Its critical to have type safety, or else we are asking people
      to take a step back in order to take a step forward.



      The combination of the above means that named pointcuts are
      really very solid abstractions of logical events. This means
      we can easily change things on either the defining or the use
      side of a named pointcut.

      For example, I can change the definition of move() to:

      pointcut move(): call(void FigureElement+.set*(..))
      && initialization(FigureElement);

      without having to first go and look at all the advice that
      directly or indirectly depends on move. Or I can add some
      new advice without having to look at the exact definition
      of move().


      Note that when I say "without having to go and look" I mean
      it in exactly the sense as we can change a procedure body
      without having to go and look at all the callers, or add a
      new call to a procedure without having to go and look at
      the body of the procedure. By this I mean that the name
      of the procedure, the result type and the argument types
      define an interface, and many changes are possible that
      stay within the bounds of the interface. So what this
      really means is that we OFTEN don't have to go look. Of
      course sometimes we do, for procedures or pointcuts.

      The guarantee we get is just like with statically typed
      procedures. If we keep the pointcut interface the same
      we can change either side and know that the program will
      still compile and weave.



      --extensible--

      The combination of the above properties, and in particular the
      orthogonality of the join point model makes AspectJ feel fairly
      extensible. For example, when we added advice execution join
      points we just had to add the join points and a new pointcut.
      They just dropped into the language with no other problems. We
      can't be sure of course about future extensions, but we have
      some optimism about this based on our experience so far.


      --other properties--

      There are a number of other critical properties that AspectJ
      has that any AOP for Java should also have. Because this message
      is already long, I will just list them:

      - static advice (declare warning, error, soften)
      - intertype declarations
      - code structure model (support IDE and other browser tools)
      - Open Source open standard


      The next step is to address to what extent the other proposals
      have these properties, in particular to what extent Bill's new
      design does. I'd appreciate the help, since I don't know the
      details of Bill's new design.

        • 1. Re: key properties of AOP in Java
          marc.fleury

          Woaaa,

          gregork... we are just getting started here and already my assignement is to read your stuff and try to make sense of it for my little friends here.


          > The purpose of the messages is to compare some of the
          > newer proposals,
          > like Rickard's, JBoss, Jadvise and AspectWerkz to
          > "good old fashioned"
          > AspectJ.

          Fair enough


          > I believe other AOP systems should also have, and
          > start a discussion
          > about whether the other proposals have those
          > properties, could have
          > those properties, and whether it would be a good
          > idea.

          Sounds good also you will find we can actually try some of it fast in AOP/JBoss.

          > This initial message just enumerates and describes
          > some key properties
          > of AspectJ. The message is primarily focused on the
          > pointcuts and
          > advice part of AspectJ.


          > -pointcut language is compositional-
          >
          > The pointcut language is compositional. This means
          > that you
          > can take pointcuts and compose them to form other
          > pointcuts.
          > This means that you can build up crosscutting
          > structure in
          > a similar manner to what we know about building up
          > procedural
          > structure or class structure.

          Be precise makes little sense as is. Right now we have precise requirements for JBoss System that we must able to say 'on this method/field/constructor' please apply this set of interceptors. We can do dynamically.

          One of the things that would be nice is a more evolved language that enables us to provide multiple pointcuts in one sentence such as
          "apply these interceptors to methods having to do with CRUD operations" a "where get/set create/delete, intercept" kind of thing. Can you give me use cases of evolved languages?.



          > The combination of supporting named abstraction and
          > being
          > compositional means we can say nice things like:
          >
          > after() returning: move() && !cflowbelow(move()) {
          > Display.update();
          > }
          >
          > and easily understand what that means.

          not here not really. You are saying that after you return from move() and you are not in the control of "move" itself you do something.

          hmmmmm, in the case of system AOP ala JBoss I am not sure I see a use for the named abstractions. I can say the above where the pointcut is a method/field/constructor/interface method but where do I need a more evolved language?

          > -static typing-
          >
          > Pointcut and advice declarations in AspectJ are
          > statically
          > typed. This supports separate compilation and it
          > means that
          > that actual weaving becomes typesafe.

          That's nice, but we don't know at writing/compile time that the aspect is going to be weaved in. For example objects that are going to be replicated across caches we instrument dynamically, objects that are going to be monitored on a method basis (counters) can be added dynamically to the class.

          The interceptor that does the work itself is in java so the logic inside is type-safe. But the issue of weaving in that aspect at run time is feasable and works because we are in a detyped environment and because the aspects are completely orthogonal. That is why we can bring them in out of the blue.

          I don't see why 'type safety' brings you for AOP combination of behavior.

          > the
          > weaving can happen later than compile time, like load
          > time
          > or even in the VM.

          you still assume a type.

          For me there are 2 types of aspects: typed ones, detyped ones.

          Detyped ones are the system ones. They support the "invoke()" signature in a "chain of responsibility" pattern it is also the signature exposed by JMX dynamic puppies. They can be weaved under the methods of instances dynamically.

          Some interceptors come typed, meaning they expose an interface for simplicity's sake and for end users (think standard mbeans). Dynamically composing that signature as a sum of the signature is what Dynamic Proxies used to do and what JBossAOP does today with Chiba's bytecode chirurgical kit.



          > Its critical to have type safety, or else we are
          > asking people
          > to take a step back in order to take a step forward.

          see above, how can you know the types upfront, you are assuming a finite set of system aspects and bill is cranking them out every other week or so, you can't control that set of behavior unless you are doing EJB stuff. EJB defines the set.

          > The combination of the above means that named
          > pointcuts are
          > really very solid abstractions of logical events.

          But is programming in logical events, nothing more than following a thread? My mind is twisted, is it really simpler?

          > --extensible--
          >
          > The combination of the above properties, and in
          > particular the
          > orthogonality of the join point model makes AspectJ
          > feel fairly
          > extensible. For example, when we added advice
          > execution join
          > points we just had to add the join points and a new
          > pointcut.

          I believe you are talking about the extensions to the language itself meaning AspectJ. Are you not? We use Java, and I will let others who know more than I do talk.

          In our case we are dealing with java objects and the java language. Are we running into some limitations of the language? yes we are. For example pointcut 'hooks" should be present in all classes at the Object level. So we can instrument our stuff through the "Advisable" interface. Domain of application is cache, transaction, acidity, possibly cmp. The fact that this construct is not present on the Object class is a pain that we need to circumvent with javassist. Also the fact that we can't instrument jdk system classes is a bitch. But we can code around it since Paris. In any case we have already run with Bill in many "mmm I wish this was a feature of the language".

          In both cases we are thinking that we should hijack kaffe and breathe new life into it, we need a kickass VM not for performance we got mr moore for that, but for raw functionality of the bytecode. Or then again, wasn't the VM already designed for that? i mean that bill through chiba's stuff is pretty much capable of enhancing any standard java class already sooo we don't need a new VM, the java bytecode language enables us to do that at the system level.

          I am worried about the "need for a language". Is what you want to do "dynamic composition of aspects"? then (uml/xml) language thing is probably enough to specify those pointcuts for most cases.

          For me it is very visual, you can see what classes have what instrumentation and what interfaces and bla bla bla. It's visual.


          > --other properties--
          >
          > There are a number of other critical properties that
          > AspectJ
          > has that any AOP for Java should also have. Because
          > this message
          > is already long, I will just list them:
          >
          > - static advice (declare warning, error, soften)
          > - intertype declarations

          I don't know what they are.

          > - code structure model (support IDE and other
          > r browser tools)

          yes UML :) or a visual thingy on running instances. Ooooh as a sys-admin I walk in, I can say "system: give me the points of entry to this system" it returns the set of objects that have remote capabilities (JBoss remote ports, AOP remotes). It is represented by a "circle" on the screen, you can drag and drop the aspect of "monitor entry for patterns of attack DOS" onto that circle thereby instrumenting your system dynamically. Bonus, baby you are my fix.

          As a developper, I can look at my system and say "these objects should be remote and these objects should be cached, and these objects should be cmp'd". Yannis of G-Tech has a whole automated thingy that does the remoteness part by itself, we just submitted a paper with Yannis doing it with AspectJ actually. It ends up in a lot of XML but we are talking visual drawing here.

          > - Open Source open standard
          >

          hell yeah!

          > have these properties, in particular to what extent
          > Bill's new
          > design does. I'd appreciate the help, since I don't
          > know the
          > details of Bill's new design.

          I'll let someone more savvy than me answer, I just appreciate you taking the time to help us get it right. Also bill used to be your student and I promise he will pay attention in class.


          • 2. Re: key properties of AOP in Java
            marc.fleury

            Woaaa,

            gregork... we are just getting started here and already my assignement is to read your stuff and try to make sense of it for my little friends here.


            > The purpose of the messages is to compare some of the
            > newer proposals,
            > like Rickard's, JBoss, Jadvise and AspectWerkz to
            > "good old fashioned"
            > AspectJ.

            Fair enough


            > I believe other AOP systems should also have, and
            > start a discussion
            > about whether the other proposals have those
            > properties, could have
            > those properties, and whether it would be a good
            > idea.

            Sounds good also you will find we can actually try some of it fast in AOP/JBoss.

            > This initial message just enumerates and describes
            > some key properties
            > of AspectJ. The message is primarily focused on the
            > pointcuts and
            > advice part of AspectJ.


            > -pointcut language is compositional-
            >
            > The pointcut language is compositional. This means
            > that you
            > can take pointcuts and compose them to form other
            > pointcuts.
            > This means that you can build up crosscutting
            > structure in
            > a similar manner to what we know about building up
            > procedural
            > structure or class structure.

            Be precise makes little sense as is. Right now we have precise requirements for JBoss System that we must able to say 'on this method/field/constructor' please apply this set of interceptors. We can do dynamically.

            One of the things that would be nice is a more evolved language that enables us to provide multiple pointcuts in one sentence such as
            "apply these interceptors to methods having to do with CRUD operations" a "where get/set create/delete, intercept" kind of thing. Can you give me use cases of evolved languages?.



            > The combination of supporting named abstraction and
            > being
            > compositional means we can say nice things like:
            >
            > after() returning: move() && !cflowbelow(move()) {
            > Display.update();
            > }
            >
            > and easily understand what that means.

            not here not really. You are saying that after you return from move() and you are not in the control of "move" itself you do something.

            hmmmmm, in the case of system AOP ala JBoss I am not sure I see a use for the named abstractions. I can say the above where the pointcut is a method/field/constructor/interface method but where do I need a more evolved language?

            > -static typing-
            >
            > Pointcut and advice declarations in AspectJ are
            > statically
            > typed. This supports separate compilation and it
            > means that
            > that actual weaving becomes typesafe.

            That's nice, but we don't know at writing/compile time that the aspect is going to be weaved in. For example objects that are going to be replicated across caches we instrument dynamically, objects that are going to be monitored on a method basis (counters) can be added dynamically to the class.

            The interceptor that does the work itself is in java so the logic inside is type-safe. But the issue of weaving in that aspect at run time is feasable and works because we are in a detyped environment and because the aspects are completely orthogonal. That is why we can bring them in out of the blue.

            I don't see why 'type safety' brings you for AOP combination of behavior.

            > the
            > weaving can happen later than compile time, like load
            > time
            > or even in the VM.

            you still assume a type.

            For me there are 2 types of aspects: typed ones, detyped ones.

            Detyped ones are the system ones. They support the "invoke()" signature in a "chain of responsibility" pattern it is also the signature exposed by JMX dynamic puppies. They can be weaved under the methods of instances dynamically.

            Some interceptors come typed, meaning they expose an interface for simplicity's sake and for end users (think standard mbeans). Dynamically composing that signature as a sum of the signature is what Dynamic Proxies used to do and what JBossAOP does today with Chiba's bytecode chirurgical kit.



            > Its critical to have type safety, or else we are
            > asking people
            > to take a step back in order to take a step forward.

            see above, how can you know the types upfront, you are assuming a finite set of system aspects and bill is cranking them out every other week or so, you can't control that set of behavior unless you are doing EJB stuff. EJB defines the set.

            > The combination of the above means that named
            > pointcuts are
            > really very solid abstractions of logical events.

            But is programming in logical events, nothing more than following a thread? My mind is twisted, is it really simpler?

            > --extensible--
            >
            > The combination of the above properties, and in
            > particular the
            > orthogonality of the join point model makes AspectJ
            > feel fairly
            > extensible. For example, when we added advice
            > execution join
            > points we just had to add the join points and a new
            > pointcut.

            I believe you are talking about the extensions to the language itself meaning AspectJ. Are you not? We use Java, and I will let others who know more than I do talk.

            In our case we are dealing with java objects and the java language. Are we running into some limitations of the language? yes we are. For example pointcut 'hooks" should be present in all classes at the Object level. So we can instrument our stuff through the "Advisable" interface. Domain of application is cache, transaction, acidity, possibly cmp. The fact that this construct is not present on the Object class is a pain that we need to circumvent with javassist. Also the fact that we can't instrument jdk system classes is a bitch. But we can code around it since Paris. In any case we have already run with Bill in many "mmm I wish this was a feature of the language".

            In both cases we are thinking that we should hijack kaffe and breathe new life into it, we need a kickass VM not for performance we got mr moore for that, but for raw functionality of the bytecode. Or then again, wasn't the VM already designed for that? i mean that bill through chiba's stuff is pretty much capable of enhancing any standard java class already sooo we don't need a new VM, the java bytecode language enables us to do that at the system level.

            I am worried about the "need for a language". Is what you want to do "dynamic composition of aspects"? then (uml/xml) language thing is probably enough to specify those pointcuts for most cases.

            For me it is very visual, you can see what classes have what instrumentation and what interfaces and bla bla bla. It's visual.


            > --other properties--
            >
            > There are a number of other critical properties that
            > AspectJ
            > has that any AOP for Java should also have. Because
            > this message
            > is already long, I will just list them:
            >
            > - static advice (declare warning, error, soften)
            > - intertype declarations

            I don't know what they are.

            > - code structure model (support IDE and other
            > r browser tools)

            yes UML :) or a visual thingy on running instances. Ooooh as a sys-admin I walk in, I can say "system: give me the points of entry to this system" it returns the set of objects that have remote capabilities (JBoss remote ports, AOP remotes). It is represented by a "circle" on the screen, you can drag and drop the aspect of "monitor entry for patterns of attack DOS" onto that circle thereby instrumenting your system dynamically. Bonus, baby you are my fix.

            As a developper, I can look at my system and say "these objects should be remote and these objects should be cached, and these objects should be cmp'd". Yannis of G-Tech has a whole automated thingy that does the remoteness part by itself, we just submitted a paper with Yannis doing it with AspectJ actually. It ends up in a lot of XML but we are talking visual drawing here.

            > - Open Source open standard
            >

            hell yeah!

            > have these properties, in particular to what extent
            > Bill's new
            > design does. I'd appreciate the help, since I don't
            > know the
            > details of Bill's new design.

            I'll let someone more savvy than me answer, I just appreciate you taking the time to help us get it right. Also bill used to be your student and I promise he will pay attention in class.


            • 3. What about MetaData?
              bill.burke

              One thing I didn't see about your post is the ability to attach metadata to a class or a given instance. Generic system-level advices need metadata to perform their functions. Perfect examples are security and transactions.

              For security, for a given method, we need to know what roles are allowed to invoke on the method. For transactions, we need to know whether to start or suspend a transaction. Does AspectJ provide such a facility?

              This is one of the things I wanted to accomplish with JBoss AOP xml configuration. A clean separation from interceptor, pointcut, and metadata definitions so that an advise can be typeless and be applicable to any type of class, yet obtain class specific metadata from a facility.

              Bill

              • 4. Re: What about MetaData?
                bill.burke

                Expanding on the idea of metadata, I also want these generic advices driven by metadata that can be resolved solely by the context of the invocation.

                Examples:

                1. Logging. For this particular thread, I want very verbose logging for every method called.

                2. Persistence queries. For this particular thread, I want a larger page sized returned.

                3. QoS. For this particular user, I want them to have a higher priority for execution.

                This is all metadata being passed back and forth at the interceptor level. Advices should have a mechanism for setting contextual information back and forth through the chain of invocation.

                You see what I'm getting at? Totally dynamic configuration fine-grained control. At the thread level, or cluster-wide.

                > One thing I didn't see about your post is the ability
                > to attach metadata to a class or a given instance.
                > Generic system-level advices need metadata to
                > perform their functions. Perfect examples are
                > security and transactions.
                >
                > For security, for a given method, we need to know
                > what roles are allowed to invoke on the method. For
                > transactions, we need to know whether to start or
                > suspend a transaction. Does AspectJ provide such a
                > facility?
                >
                > This is one of the things I wanted to accomplish with
                > JBoss AOP xml configuration. A clean separation from
                > interceptor, pointcut, and metadata definitions so
                > that an advise can be typeless and be applicable to
                > any type of class, yet obtain class specific metadata
                > from a facility.
                >
                > Bill

                • 5. Dynamic AOP
                  bill.burke

                  Besides metadata, system-level aspects have a strong need for dynamic AOP. I define this as the ability to attach metadata to an instance dynamically at runtime, or the ability to add an interceptor to a given class or instance as well. Dynamic interception of constructor, fields, or methods. As Marc has already stated, we need this for remoting, transactional caching, replication, and probably persistence as well.

                  This is one of the reasons we felt we could not go with AspectJ. Please address this issue of you can.

                  Thanks,

                  Bill

                  • 6. Re: Dynamic AOP
                    marc.fleury

                    > Besides metadata, system-level aspects have a strong
                    > need for dynamic AOP. I define this as the ability to
                    > attach metadata to an instance dynamically at
                    > runtime, or the ability to add an interceptor to a
                    > given class or instance as well. Dynamic interception
                    > of constructor, fields, or methods. As Marc has
                    > already stated, we need this for remoting,
                    > transactional caching, replication, and probably
                    > persistence as well.
                    >
                    > This is one of the reasons we felt we could not go
                    > with AspectJ. Please address this issue of you can.

                    Well I don't think this discussion is about using AspectJ, it is rather about what is the right way to specify what and where.

                    The what is what you do, for example specify the role for the security thing and then put all the stacks together with a logical name and have that configurable through a stack mbean configuration.

                    Then the class/app whatever should just reference that configuration through the logical name. Then the client (as in the case of read-ahead) can overwrite the value through the interface and passing the values.

                    The where is the specification of 'where do you apply that logical configuration of interception (what interceptors and what configuration). UML may be a simple way, whereas Gregor is thinking about pure languages to do it. I am leaning towards your side which is that we can do it simply with XML and logical configurations

                    • 7. Re: key properties of AOP in Java

                      > > The pointcut language is compositional. This
                      > means
                      > > that you
                      > > can take pointcuts and compose them to form other
                      > > pointcuts.
                      > > This means that you can build up crosscutting
                      > > structure in
                      > > a similar manner to what we know about building up
                      > > procedural
                      > > structure or class structure.
                      >
                      > Be precise makes little sense as is. Right now we
                      > have precise requirements for JBoss System that we
                      > must able to say 'on this method/field/constructor'
                      > please apply this set of interceptors. We can do
                      > dynamically.

                      Composition is more useful at the app developer level for "application aspects" although it definitely would be useful at the system level as well -- even though the specified sets at system level are predefined and therefore easily handled by other means.


                      > One of the things that would be nice is a more
                      > evolved language that enables us to provide multiple
                      > pointcuts in one sentence such as
                      > "apply these interceptors to methods having to do
                      > with CRUD operations" a "where get/set create/delete,
                      > intercept" kind of thing. Can you give me use cases
                      > of evolved languages?.

                      This is composition. First you have a definition of a set of methods/fields 'A' and for example two defined sets of interceptors; one stack 'M' of CMP persistence interceptors another stack 'N' for Tx/Locking.

                      You compose these definitions into a component contract 'X' by joining them to apply to a specific set of methods where you want the persistence and transaction/locking construct enforced. Essentially you define 'X' to say "if my objects contain signatures A I want to apply M+N". From that point on you can advice your POJO to fulfill contract X directly.

                      This is a point about giving more expressive power to the developer.


                      > hmmmmm, in the case of system AOP ala JBoss I am not
                      > sure I see a use for the named abstractions. I can
                      > say the above where the pointcut is a
                      > method/field/constructor/interface method but where
                      > do I need a more evolved language?

                      Have a look at the current standardjboss.xml file. About thousand or so lines of configuration that basically just repeats itself. And this is to cover just a few basic cases of fulfilling the EJB service contract. This is where composition (via inheritance) even at system level would be helpful although of more limited use compared to application level.

                      It might be that XML schema is enough -- although I have my doubts relying too much on the XML garbage files. Failure at component level already, who wants it at the object level?

                      Anyhow, composition at the application level would serve the developer quite well as we're unable to provide the defaults at that point.

                      > I don't see why 'type safety' brings you for AOP
                      > combination of behavior.

                      It is clear that the type safety requirements absolutely must be relaxed for "system aspects". The framework has no way of knowing at compile time the types of the components (since we want to do away with any kind of mandatory component contract). At system level giving up the type safety might not be that much of an issue anyway -- yes it may be painful for a while until all the wrinkles get ironed out but we can assume that eventually "we'll get it right". This code will be shared across so many different services that bugs related to non-typed invocations should surface fairly quickly.

                      Again, different picture at the app level. A simple case (so simple it might already have been adressed). I don't want to track down through all my interceptor stack definitions just because I decided to change a method name on my POJO and whatever configuration existed for that method does not apply anymore because of signature mismatch (btw, composition plays a large role in how much 'tracking' I would have to do).

                      On the other hand, we gave up partially on type safety with EJB component contract already (so even at app level) when the interfaces were separated from the implementation. And seeing that custom compilers would be difficult to get accepted and rather top heavy approach it may be that we need to rely on a similar 'verifier/xdoclet/etc' preprocessor strategy we used with EJBs.

                      > Some interceptors come typed, meaning they expose an
                      > interface for simplicity's sake and for end users
                      > (think standard mbeans). Dynamically composing that
                      > signature as a sum of the signature is what Dynamic
                      > Proxies used to do and what JBossAOP does today with
                      > Chiba's bytecode chirurgical kit.

                      This is fine if the intended advices, introductions and metadata can all be determined from the naming conventions of a statically typed interface. But it seems unlikely. So you still end up with part of the contract located outside the Java language (assuming no language extensions, JSR175) which naturally loses any type safety from the programmers point of view.

                      Of course, the same problem exists for EJBs as well (part of why the price of writing an EJB component contract is so high). There still doesn't seem to be a good solution for this (although XDoclet manages to relieve the nastiest symptoms) and I doubt there will be anything outside extending the language itself (via JSR175 or otherwise).

                      > I am worried about the "need for a language".

                      Need for language is always about adding abstraction and more expressiveness to the application developer (and less places to fuck it all up). Everything can be equally expressed with a "lower" level language. Turing complete. No point in arguing that.

                      • 8. Re: What about MetaData?
                        gregork

                        > One thing I didn't see about your post is the ability
                        > to attach metadata to a class or a given instance.
                        > Generic system-level advices need metadata to
                        > perform their functions. Perfect examples are
                        > security and transactions.

                        I didn't include that explicitly. Once JSR-175 is done
                        it will be natural for AspectJ to support this through
                        the thisJoinPoint object. Something like:

                        thisJoinPoint.getSignature().getAnnotations()

                        or something like that. I agree this will be very useful
                        as a way of communicating information about specific
                        member declarations to generic aspects.

                        > This is one of the things I wanted to accomplish with
                        > JBoss AOP xml configuration. A clean separation
                        > from interceptor, pointcut, and metadata definitions
                        > so that an advise can be typeless and be applicable
                        > to any type of class, yet obtain class specific
                        > metadata from a facility.

                        As described above, I think this should be a property
                        of join points. That makes it nicely orthogonal with
                        pointcuts and advice (whatever syntax you use for
                        pointcuts and advice).

                        • 9. Re: key properties of AOP in Java
                          gregork

                          > > The pointcut language is compositional.
                          >
                          > Be precise makes little sense as is.

                          I believe Juha already addressed this.

                          > One of the things that would be nice is a more
                          > evolved language that enables us to provide
                          > multiple pointcuts in one sentence such as
                          > "apply these interceptors to methods having to do
                          > with CRUD operations...

                          and this.

                          > hmmmmm, in the case of system AOP ala JBoss I
                          > am not sure I see a use for the named
                          > abstractions.

                          and this.

                          > > Pointcut and advice declarations in AspectJ are
                          > > statically typed.
                          >
                          > That's nice, but we don't know at writing/compile
                          > time that the aspect is going to be weaved in. For
                          > example ...
                          >
                          > The interceptor that does the work itself is in java
                          > so the logic inside is type-safe. But the issue of
                          > weaving in that aspect at run time is feasable and
                          > works because we are in a detyped environment and
                          > because the aspects are completely orthogonal.
                          > ...
                          > For me there are 2 types of aspects: typed ones,
                          > detyped ones.
                          >
                          > Detyped ones are the system ones.

                          What you are saying here is that many generic
                          aspects are, roughly speaking, typed to Object.

                          There's no doubt that's true. But note that:

                          - that's still statically typed, for example the code
                          in question is sure it isn't going to get an unboxed
                          int

                          - just because some aspects are that generic
                          doesn't mean that all will be, especially down
                          the road when you open this up to users

                          - and if you don't get static typing in from the start,
                          your unlikely to be able to add it later as a
                          compatible change

                          In 1998, AspectJ was dynamically typed, about like
                          you are proposing. It took some hard work to figure
                          out how to make it statically typed. Its a much better
                          tool now for it, because when I do want to write an
                          aspect that is specific to a certain system, I get all
                          the benefits of static typing that Java programmers
                          are familiar with.

                          • 10. Re: What about MetaData?
                            bill.burke

                            > > One thing I didn't see about your post is the
                            > ability
                            > > to attach metadata to a class or a given instance.
                            > > Generic system-level advices need metadata to
                            > > perform their functions. Perfect examples are
                            > > security and transactions.
                            >
                            > I didn't include that explicitly. Once JSR-175 is
                            > done
                            > it will be natural for AspectJ to support this
                            > through
                            > the thisJoinPoint object. Something like:
                            >
                            > thisJoinPoint.getSignature().getAnnotations()
                            >
                            > or something like that. I agree this will be very
                            > useful
                            > as a way of communicating information about specific
                            > member declarations to generic aspects.
                            >

                            I'm thinking a little bit more than JSR175. I want the framework to be able to either allow overrides at the Thread level or be able to provide defaults cluster-wide. To do this the framework would need to have some control over how metadata is resolved.

                            Bill

                            • 11. Let's summarize later.
                              bill.burke

                              After we thrash about on this thread for awhile, I'll start a new topic with a summarization of bulletpoints of this thread.

                              • 12. Concept of an Abstract Container
                                bill.burke

                                One concept I've been fooling around with in JBoss AOP is the concept of an Abstract Container. What if you wanted to define different sets of pointcuts/advices/whatever to the same Java class? A definition of an abstract container could provide this facility. I have implemented this in our framework:



                                <container-pointcut container="POJOJ2EE">
                                <interceptor-ref "Transactions"/>
                                <interceptor-ref "Security/>
                                </container-pointcut>

                                <container-metadata container="POJOJ2EE">

                                <trans-attribute>RequiresNew</trans-attribute>

                                </container-metadata>

                                • 13. Type safety
                                  bill.burke

                                  >
                                  > > I don't see why 'type safety' brings you for AOP
                                  > > combination of behavior.
                                  >
                                  > Again, different picture at the app level. A simple
                                  > case (so simple it might already have been adressed).
                                  > I don't want to track down through all my interceptor
                                  > stack definitions just because I decided to change a
                                  > method name on my POJO and whatever configuration
                                  > existed for that method does not apply anymore
                                  > because of signature mismatch (btw, composition
                                  > plays a large role in how much 'tracking' I would
                                  > have to do).
                                  >

                                  Let's figure out the use cases where type safety is needed and where we can add it.

                                  Application of pointcuts and metadata is one area we can improve on type safety by having the framework test that a method, field, constructor asking for interception/metadata in XML actually exists.


                                  > On the other hand, we gave up partially on type
                                  > safety with EJB component contract already (so even
                                  > at app level) when the interfaces were separated from
                                  > the implementation. And seeing that custom compilers
                                  > would be difficult to get accepted and rather top
                                  > heavy approach it may be that we need to rely on a
                                  > similar 'verifier/xdoclet/etc' preprocessor strategy
                                  > we used with EJBs.
                                  >
                                  > > Some interceptors come typed, meaning they expose
                                  > an
                                  > > interface for simplicity's sake and for end users
                                  > > (think standard mbeans). Dynamically composing
                                  > that
                                  > > signature as a sum of the signature is what
                                  > Dynamic
                                  > > Proxies used to do and what JBossAOP does today
                                  > with
                                  > > Chiba's bytecode chirurgical kit.
                                  >
                                  > This is fine if the intended advices, introductions
                                  > and metadata can all be determined from the naming
                                  > conventions of a statically typed interface. But it
                                  > seems unlikely. So you still end up with part of the
                                  > contract located outside the Java language (assuming
                                  > no language extensions, JSR175) which naturally loses
                                  > any type safety from the programmers point of view.
                                  >
                                  > Of course, the same problem exists for EJBs as well
                                  > (part of why the price of writing an EJB component
                                  > contract is so high). There still doesn't seem to be
                                  > a good solution for this (although XDoclet manages to
                                  > relieve the nastiest symptoms) and I doubt there will
                                  > be anything outside extending the language itself
                                  > (via JSR175 or otherwise).
                                  >
                                  > > I am worried about the "need for a language".
                                  >
                                  > Need for language is always about adding abstraction
                                  > and more expressiveness to the application developer
                                  > (and less places to fuck it all up). Everything can
                                  > be equally expressed with a "lower" level language.
                                  > Turing complete. No point in arguing that.
                                  >

                                  • 14. Re: key properties of AOP in Java
                                    marc.fleury

                                    > Composition is more useful at the app developer level
                                    > for "application aspects" although it definitely
                                    > would be useful at the system level as well -- even
                                    > though the specified sets at system level are
                                    > predefined and therefore easily handled by other
                                    > means.

                                    Composition of aspects with typed interceptors are a real use case yes, but I want to see use cases of the "language" that specifies the pointcuts.

                                    I am thinking about a mix between sql/uml

                                    > This is a point about giving more expressive power to
                                    > the developer.

                                    Expressing meta=containers (which you essentially just describe) is something that is in the plans with pure XML. Give a logical name to a configuration of a stack (== composition) and then apply that "composition" to the pointcuts you specify.

                                    Where I am fuzzy and need more help understanding clearly is "do we need a full blown language" to make application of aspects (logical, composed or what have you) easier to use. My gut feeling is that expressing pointcuts in a powerful fashion is a mix of query on properties + Graphical stuff.

                                    We are doing it with XML and the expressive power is already good.

                                    > Have a look at the current standardjboss.xml file.
                                    > About thousand or so lines of configuration that
                                    > basically just repeats itself. And this is to cover
                                    > just a few basic cases of fulfilling the EJB service
                                    > contract. This is where composition (via inheritance)
                                    > even at system level would be helpful although of
                                    > more limited use compared to application level.

                                    prove it :)

                                    all we are talking about is xml stuff here, nothing revolutionary, not a new language (yet). I just want to make sure we check with a critical eye the "language" requirement. For example the EJB file thing, yes you repeat the stack of interceptors for every container, but already container is an abstract construct and the USER just deploys an EJB of a certain type (say entity) and the system KNOWS to apply that container to that class.

                                    Meaning, your point is a bit moot in my mind. We have 2 audiences

                                    1- the container designer, who is QUITE HAPPY with logical configuration of container/app aspect (bill and rickard do this)

                                    2- the user of the framework, who doesn't need to do anything in EJB and can easily slip into role 1 as needed.

                                    > Anyhow, composition at the application level would
                                    > serve the developer quite well as we're unable to
                                    > provide the defaults at that point.

                                    yes

                                    > It is clear that the type safety requirements
                                    > absolutely must be relaxed for "system aspects".

                                    agreed

                                    > framework has no way of knowing at compile time the
                                    > types of the components (since we want to do away
                                    > with any kind of mandatory component contract). At
                                    > system level giving up the type safety might not be
                                    > that much of an issue anyway -- yes it may be painful
                                    > for a while until all the wrinkles get ironed out but
                                    > we can assume that eventually "we'll get it right".

                                    yes. Typeless is important to 'weave' orthogonal aspects transparently in the going flow of a call. I even believe it is almost a requirement.

                                    > Again, different picture at the app level. A simple

                                    yes, user wants interfaces.

                                    > I don't want to track down through all my interceptor
                                    > stack definitions just because I decided to change a
                                    > method name on my POJO and whatever configuration
                                    > existed for that method does not apply anymore
                                    > because of signature mismatch (btw, composition
                                    > plays a large role in how much 'tracking' I would
                                    > have to do).

                                    If you are specifying pointcuts on methods then the doclet approach is best. Don't create a dependency on the name just generate the xml. The XML file may still be the easiest way to express the configuration. I view the XDoclet/dotnet approach as 'nice front end' to the xml file.

                                    > the implementation. And seeing that custom compilers
                                    > would be difficult to get accepted and rather top
                                    > heavy approach it may be that we need to rely on a
                                    > similar 'verifier/xdoclet/etc' preprocessor strategy
                                    > we used with EJBs.

                                    yes, maybe.

                                    It is one of these things... until I am forced to abandon XML i am not inclined to. The benefit is still abstract.

                                    > This is fine if the intended advices, introductions
                                    > and metadata can all be determined from the naming
                                    > conventions of a statically typed interface. But it
                                    > seems unlikely. So you still end up with part of the
                                    > contract located outside the Java language (assuming
                                    > no language extensions, JSR175) which naturally loses
                                    > any type safety from the programmers point of view.

                                    Specifying pointcuts on interfaces (already in JBOSS) or specifying pointcuts on POJO (also in JBOSS) isn't the question right? when you say "it seems unlikely we can express all we want" my question is "give me an example".

                                    System level aspects are happy with regexp expression of application (such as apply state tracking interceptor to CRUD operations and configure them for cache replication) is already in CVS fwict.

                                    Applying logical stacks of interceptors AT CERTAIN POINTS IN THE FLOW OF LOGIC is something possibly best expressed by a rules engine.

                                    > Of course, the same problem exists for EJBs as well
                                    > (part of why the price of writing an EJB component
                                    > contract is so high). There still doesn't seem to be
                                    > a good solution for this (although XDoclet manages to
                                    > relieve the nastiest symptoms) and I doubt there will
                                    > be anything outside extending the language itself
                                    > (via JSR175 or otherwise).

                                    we are making a mountain out of a mole hill... specifying EJB is a pain? come on... we are purely in logical containers and the pointcut specification is well defined (with requirements of get/set). The price isn't high, in fact it is the requirement we enforce today (get/set) although bill has ways to do it at field interception.

                                    Bill says he can do it, so does Eli of georgia tech... but the instrumentation is a bit heavy at the classloader level with some dependency issues that we haven't looked at yet. It is the reason why I finally gave up on the field interception thread on this very forum.

                                    You are correct transparent state change tracking for example is something that is MISSING at the bytecode level and we have to go through hoops to achieve a simple VM level feature which reads
                                    - any time someone changes the state indirect somewhere in the class itself
                                    in this case we should have a language extension.

                                    I don't know if 175 addresses this at all. Gregork is on the expert committee maybe you can shed some light.

                                    > Need for language is always about adding abstraction
                                    > and more expressiveness to the application developer
                                    > (and less places to fuck it all up). Everything can
                                    > be equally expressed with a "lower" level language.
                                    > Turing complete. No point in arguing that.

                                    you sound like a bulshit consultant :)

                                    oh no, the plasticmen are coming! they are coming!
                                    --Doctoring the house--

                                    1 2 Previous Next