commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Art Gramlich <...@gramlich-net.com>
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 
is
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.
>
> WDYT?

Obviously this would be the best implementation.  It seems that it would
be very heavyweight though and require a full recompilation of any 
dynamic
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message