commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Art Gramlich <>
Subject Re: [javaflow] Transforming classes that implement Continuable
Date Thu, 24 Feb 2005 02:56:04 GMT

On Feb 21, 2005, at 1:09 AM, Torsten Curdt wrote:

>> 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 ;)

Looks like the path of least resistance.  The patch I posted
earlier (the second fixed one) was a quick hack I threw together
to test the idea of passing in root packages to do transformation on.
While looking at it , I noticed that if the test case "tests" are moved 
into a
child package, that the entire section where the non-transformed class 
defined in the current classloader can be removed and these can be 
delegated to
the parent loader instead.  Again at this point I may be missing 
something.  Am I
wrong about this?

> 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.

Obviously this would be the best implementation.  It seems that it would
be very heavyweight though and require a full recompilation of any 
classes in order to find any calls.  Also, couldn't someone get sneaky
and use reflection to call suspend (let's hope not) :-).

> cheers
> --
> Torsten

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message