Re: [aspectj-users] Bytecode weaving and JRE classes

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

Hi -

> I too am interested in aspecting java.* classes. I have seen several
> postings on this issue looking for an answer, But haven't seen any
> replies yet :(

Eclipse.org lets you search the mailing lists.  E.g., for
"do not use bytecode weaving" on aspectj-users, this was first:

  http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg00846.html

>> I'm trying to implement a java.awt.Toolkit (and all that it produces)
>> so that AWT and Swing applications can be
>> accessed locally, or remotely.  <snip>

Swingaway looks like a great idea that could fill a strong need.
I know nothing about jiapi, but would also recommend JMangler
if you really want to do load-time transformations.  It seems
safe and easy to write for.

  http://javalab.cs.uni-bonn.de/research/jmangler/

But do you have to instrument sun classes?  AspectJ would let you
put around advice on any call from the client code to java.awt,
and redirect it to your server.  So you'd only need to weave
the client code, and you can do that as a condition of their use.

Here's around advice that replaces all java.awt calls with
the result of the serverProxy(JoinPoint) method:

   Object around() : call(* java.awt..*.*(..))
            || call(java.awt..*.new(..)) {
        return serverProxy(thisJoinPoint); // has target, args, etc.
   }

Now that would be an interesting method to write!
So perhaps it would be your backup, lowest-precedence advice.
You could iteratively develop by implementing specific calls,
handling fewer and fewer in the backup case:

aspect HandleAwt {
   ...
   // handle actionPerformed...
   void around(ActionListener listener, Object caller) :
            this(caller) && target(listener) &&
            call(void ActionListener.actionPerformed()) {
        serverProxy_actionPerformed(caller, listener);
   }

   // handle others...

   // last advice handles any remaining...
   Object around() : call(* java.awt..*.*(..))
       ...
}

Aside from around advice, proxying could work well.
Replace the clients AWT instance with your own subclass,
and put all the proxying in the subclass.  It's best
to do this on construction:

    // replace any button constructed with our proxy
    Button around(String label) : call(Button.new(String)) {
        return ButtonProxy(label);
    }

But (in case your client doesn't create the instances)
you can also do it at other lifecycle points, e.g., when
components are added to containers:

    // replace any Component added to a Container with ours
    Component around(Component toAdd) : args(toAdd)
            && call(Component Container.add(Component)) {
        return proceed(ComponentProxies.make(toAdd));
    }

You can do cool things in pointcuts with proxies.  For
example, you can skip any advice for calls to your proxies,
easily if there's a common supertype, e.g., IServerProxy

    interface IServerProxy{}
    declare parents: ButtonProxy implements ServerProxy;

then you can use it to skip calls to instance methods:

   void around(ActionListener listener, Object caller) :
            !target(IServerProxy) &&
            this(caller) && target(listener) &&
            ...

or to issue warnings:

   before() : call(* Component.*(..))
            && !args(IServerProxy) {
       // bug! all components should be proxied at this point
   }

and you can declare fields or methods on it:

    Server IServerProxy.server;
    void IServerProxy.connect() {
        try {
             server.connect();
        ...
    }

which you can use in your advice:

   // handle actionPerformed...
   void around(IServerProxy proxy, Object caller) :
            this(caller) && target(proxy) &&
            call(void ActionListener.actionPerformed()) {
	Connection connection = proxy.connect();
        ...
   }

, etc.

David Walend last year used AspectJ to capture all calls
into and out of a certain scope, in order to be able
to replay them (interestingly, he replayed them by
generating the corresponding java code, compiling it,
and then running it).  I suspect he got a job or got
married or something silly like that because the project
has been dormant recently.  In any case, you can check
out his code to see if some of his ideas or approaches
help you.  It's at

   http://cricketcage.sourceforge.net

Please let us know whether you decide to use AspectJ.

Wes

prasenjit mukherjee wrote:

> I too am interested in aspecting java.* classes. I have seen several 
> postings on this issue looking for an answer, But haven't seen any 
> replies yet :(
>
> prasen
>
> Curt Cox wrote:
>
> > Hi,
> >
> > From the AspectJ FAQ:
> > "If you have an application for using aspects and bytecode, please let 
> > the AspectJ team know of your requirements."
> >
> > I'm evaluating AspectJ and Jiapi for a specific project.
> > https://swingaway.dev.java.net/
> >
> > I'm trying to implement a java.awt.Toolkit (and all that it produces) 
> > so that AWT and Swing applications can be
> > accessed locally, or remotely.  It currently looks like piggybacking 
> > an implementation on top of an existing one
> > would be far less work than writing one from scratch.  AspectJ and 
> > Jiapi both look like they would make the
> > piggybacking approach far easier.
> >
> > From the AspectJ FAQ:
> > "And just to state the obvious: do not use bytecode weaving, at 
> > load-time or otherwise, to modify .class files protected by license, 
> > without permission from the licensor."
> >
> > Do Sun JREs permit or prohibit bytecode weaving?
> > Is the answer the same for java.*, javax.*, sun.*, com.sun.*, and 
> > other (com.mycompany.* etc...) packages?
> >
> > Thanks,
> > Curt
> >
> >
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users