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] a problem in ResourceTransformer abstraction
Date Thu, 29 Dec 2005 01:54:28 GMT
> I found a problem in the current ResourceTransformer abstraction.
>
> Sometimes, a proper instrumentation of a class requires information  
> about other classes. Consider the following code:
>
>   // note that in bytecode, type of local
>   // variables aren't available
>   var x;
>
>   if(...) {
>     x = new Foo();
>   } else {
>     x = new Bar();
>   }
>
>   someMethodCall();
>
>   if(...) {
>     new Thread(x);
>   } else {
>     new TreeSet(x);
>   }
>
> Proper stack frame restoration at "someMethodCall" requires an  
> identification of the common base class between Foo and Bar (so  
> that an object of the right type will be set to local variable  
> 'x'), which in turns requires information about Foo and Bar.

Hmmm.... so we imply that x must be the common base of Foo and Bar,  
right?

>
> The current ResourceTransformer just takes the class file image to  
> be transformed, and therefore a ResourceTransformer implementation  
> is supposed to magically resolve Foo and Bar to the right class  
> file --- which is impossible.
>
> This is breaking my workflow engine that uses multiple class  
> loaders (where 'Foo' may resolve to different symbols, depending on  
> the context.)
>
> So I suggest we introduce a mechanism to resolve symbols to their  
> class files:
>
>   interface ClassImageLoader {
>     byte[] load(String className);
>   }
>
> ... and change ResourceTransformer as follows:
>
>   interface ResourceTransformer {
>     byte[] transform(String className, ClassImageLoader loader);
>   }
>
> Can I make this change?

Hmmm.... can you elaborate a bit more. (I am currently in the middle
of moving so don't have much time to dig into it myself)

If possible I would really keep the ResourceTransformer interface
as simple as possible!

So you want to find the base class from the "ClassImageLoader"?

> P.S. Also how stable is the ASM implementation? Should we  
> concentrate our effort on that side going forward?

Yes, I would rather like to concentrate on the ASM implementation.
...they have a great and vital community around ASM ...or what do
you think?

cheers
--
Torsten

Mime
View raw message