commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [javaflow] Transforming classes that implement Continuable
Date Mon, 21 Feb 2005 08:09:04 GMT
> While playing with javaflow, I found out the hard way that the
> ContinuationClassLoader
> is only transforming java that is in a certain package.  I made this

Sorry, about that ....of course that should be made coonfigurable.

> patch to transform
> classes that implement Continuable and leave the others alone.  This
> seems like the
> correct way to do it, but I may be missing consequences of doing it
> this way.

Hehe ...have a look into an older revision
Just recently I've removed exactly that :)

I am not a big fan of (empty) marker interfaces.
Plus this has a big impact on the behaviour of
the BCEL processing.

If you do a javaClazz.getAllInterfaces()
you need to have a all the depending classes
and interfaces already in the internal BCEL
repository.

While I did some work with ASM I found it
very nice to work with ...and so I wanted
get rid of a direct BCEL dependency. Which
also includes accessing the repository from
javaflow code other than the transformer.

BCEL tries to find and parse unknown classes
by itself ...which does not really work very
well in our case. ...with some effort this
could of course be fixed in BCEL.

...but for now I think rewriting on the
package name is quite a useable alternative
that probably will fit the real world
requirements.

As long it is configurable ;)

On the other hand it might be good to do
a full call flow analysis so we can rewrite
only those methods that might need it because
we are calling suspend.

But this would required the full dependencies
and is quite heavy weight on the load but more
light weight on the execution. Haven't made my
mind up on that yet.

WDYT?

cheers
--
Torsten

Mime
View raw message