10 Replies Latest reply on May 19, 2003 9:21 AM by spiritualmechanic

    Intercepting Private Fields/Methods

    weolopez

      I have a quick question that I haven't seen discussed here or other AOP sites that I visit. If there is a link to the discussion of this topic that would be great.

      Is it proper or even a bad thing to intercept private fields and method? Isn't that essentialy breaking encapsulation and possibly security consern.

      Will you be able to intercept 3ed party libraries and use their internals in ways that the author didn't intend?

      thanks,
      weo

        • 1. key properties of AOP in Java
          thomasra


          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.

          • 2. Re: Intercepting Private Fields/Methods
            bill.burke


            > Is it proper or even a bad thing to intercept private
            > fields and method? Isn't that essentialy breaking
            > encapsulation and possibly security consern.
            >

            Depends. For transactional objects, where you want to transparently keep track of state changes, that is a good thing.

            Even with the ability to intercept private methods, you cannot write code that accesses private methods since it just won't compile.

            As far as a security concern? java.lang.reflect.Field.setAccessible(true). Meaning, any code can access a private field through reflection. This is how JBoss AOP actually can do interception.


            > Will you be able to intercept 3ed party libraries and
            > use their internals in ways that the author didn't
            > intend?
            >

            Of course. But so what? If you're gonna be a stupid programmer, then, just be stupid.

            > thanks,
            > weo

            • 3. Re: Intercepting Private Fields/Methods
              marc.fleury

              > I have a quick question that I haven't seen discussed
              > here or other AOP sites that I visit. If there is a
              > link to the discussion of this topic that would be
              > great.
              >
              > Is it proper or even a bad thing to intercept private
              > fields and method? Isn't that essentialy breaking
              > encapsulation and possibly security consern.

              If you can do it and it feels good, jfdi as adrian says

              > Will you be able to intercept 3ed party libraries and
              > use their internals in ways that the author didn't
              > intend?

              ok, see bill's answer. The question is valid. The answer is yes we can instrument methods in 3rd party libraries. Say for example that you want to instrument JDBC drivers to scan the invocation in order to add security and plug loopholes then all you have to do is pointcut the methods you want to secure in XML and then add your magic "string watcher". So yes there are very valid uses cases for system level instrumentation of classes (done in classloaders) that allow to statically monitor a given object in the runtime in a fashion that is non-intrusive with the existing class.

              We are tired of repeating the same points, mainly that system level aspects (the ones you find in J2EE) are truly orthogonal constructs that you will want to dope your objects with.

              For example that security, the way we secure JNDI so as to make it look like the dumbed down secure login of BEA, or plainly making some parts of your j2se applications remote without coding to EJB's.

              I guess the point here is that you can take even poorly architected J2SE applications and kinda make them look like EJB's. In fact this is the way we implement EJB, by bundling aspects.

              In other yeah, and don't shoot yourselves in the foot while you are doing so, but if you do, do tell us about it, we are truly curious to see other system level aspects besides ours.

              >
              > thanks,
              > weo

              • 4. Re: Intercepting Private Fields/Methods
                dsilcox69

                Just another AspectJ newbie here. Forgive me if I'm outta my league..

                Just had a similar concern and decided the best solution was to develop inter-type code that actually added my reflection code to the target objects.

                Am thinking the design goal would be as if java could extend multiple classes - only the aspectJ code actually adds the code in. Encapsulation is not broken.

                Was wondering if this design approach held any water..

                • 5. Re: Intercepting Private Fields/Methods
                  cepage

                  > Say for example that you want to
                  > instrument JDBC drivers to scan the invocation in
                  > order to add security and plug loopholes then all you
                  > have to do is pointcut the methods you want to secure
                  > in XML and then add your magic "string watcher". So
                  > yes there are very valid uses cases for system level
                  > instrumentation of classes (done in classloaders)
                  > that allow to statically monitor a given object in
                  > the runtime in a fashion that is non-intrusive with
                  > the existing class.

                  That is such a cool use case. With AOP the user community will be able to develop and distribute patches and bugfixes to closed, proprietary software. I am geeked!

                  • 6. Re: Intercepting Private Fields/Methods
                    marc.fleury

                    > Just another AspectJ newbie here. Forgive me if I'm
                    > outta my league..

                    you are not since we are not talking about AspectJ (pardon me gregork ;)

                    > Just had a similar concern and decided the best
                    > solution was to develop inter-type code that actually
                    > added my reflection code to the target objects.

                    Wow, you want to go with JB4.0 we will speed that up tremendously.

                    > Am thinking the design goal would be as if java could
                    > extend multiple classes - only the aspectJ code
                    > actually adds the code in. Encapsulation is not
                    > broken.

                    2 different things.

                    1- extending multiple classes. That is the dynamic proxy part the part where we can do runtime multiple inheritance of classes, bill coded it for pojos, I think rickard calls this introductions. Old stuff new sauce. These are different than the detyped (typically system level) aspects.

                    2- specifying where the fuck the class goes :) that is the purpose of the language really and I believe that xml may be sufficient for many use cases, I still have to see a clear example of where more expressive languages are needed and then GO TO SCRIPTING, meaning take python and rebuild JBOSS :)


                    • 7. Re: Intercepting Private Fields/Methods
                      marc.fleury

                      > > Say for example that you want to
                      > > instrument JDBC drivers to scan the invocation in
                      > > order to add security and plug loopholes then all
                      > you
                      > > have to do is pointcut the methods you want to
                      > secure
                      > > in XML and then add your magic "string watcher".
                      > So
                      > > yes there are very valid uses cases for system
                      > level
                      > > instrumentation of classes (done in classloaders)
                      > > that allow to statically monitor a given object in
                      > > the runtime in a fashion that is non-intrusive
                      > with
                      > > the existing class.
                      >
                      > That is such a cool use case. With AOP the user
                      > community will be able to develop and distribute
                      > patches and bugfixes to closed, proprietary software.
                      > I am geeked!


                      the use case is not mine, credit where credit is due it was some "JDBC challenge" put on the web by some blogger claiming to talk about AOP, can't remember his name but he said basically that this specific use case was impossible to cover with JBoss.

                      • 8. Re: Intercepting Private Fields/Methods

                        This it seems to me is one of the more interesting side-effects of an AOP/Proxy approach. JBoss could become a language-agnostic architecture, where you could add services to any object from any language (Python, Ruby, Java, etc.).

                        Eventually things may get complicated enough to where you'd have to bump up to a higher-level language just to maintain JBoss code. Then again, while Python has great run-time capabilities, it doesn't have a VM like Java. Whatever happened to the Perl->Parrot<-Python connection? Who knows.

                        Eventually, the grand poobah ideal would be for the VM itself to be configurable, adding/dropping services, with a language/XML to tell the VM what to do at runtime.

                        Steve

                        • 9. Re: Intercepting Private Fields/Methods
                          marc.fleury

                          > Eventually things may get complicated enough to where
                          > you'd have to bump up to a higher-level language just
                          > to maintain JBoss code.

                          Right, I haven't seen that yet... yes we need to extend the language in many places but that is what javassist does for us.

                          • 10. Re: Intercepting Private Fields/Methods

                            Interesting point. I hadn't thought of that. You're right that Javassist basically gives you those capabilities, to deal with code at any level (high-level, low-level) you want.
                            Steve